You are correct in your assumption, you have to work with streams to operate on arbitrarely large JSON. %ToJSON and %FromJSON work with streams. Here is an example how streams can work with %FromJSON to read a file:

        set fileStream = ##class(%Stream.FileCharacter).%New()
        $$$THROWONERROR(tsc,fileStream.LinkToFile(<pFile>))
       
        set jsonObject = ##class(%DynamicObject).%FromJSON(fileStream)

Hi Simcha,

you can easily retrieve the data that you are using in your layout (AlerTList in your case), by calling the function getSourceData() on your documentView component. Assuming the id of your documentView is 'mainView', the following code sample should work in your environment:

var view = zen('mainView');

var data = view.getSourceData();

console.log(data.AlerTList);

HTH,

Stefan

We are in the process of updating our Hibernate dialect and plan to push the new dialect to the repository later this year. I got word from our developers that we are using the same strategy as Nicholas provided in his getDefaultMultiTableBulkIdStrategy implementation.

Thanks for sharing!

In case you are looking for an easy way to export SQL data to an Excel file as a developer:  I can recommend SQuirreL as SQL client, which offers Excel and HTML export capabilities.

I agree, Postman is a great tool.

If you want to document your REST interface, take a look at Swagger. You can generate an HTML documentation for your interface and test each call directly. 

As I mentioned before the onevent method is not directly called for most events. The onevent method is only called for viewport changes by default.

Here is an example how you can register your own events. Everything happens in the homepage class.

Step 1) Subscribe to the onPageShow callback

Most pageManagers implement the onPageShow method to let you know when a certain layout has finished rendering. This is a complete documentView example:

<mojo:documentView
 id="mainView"
ongetdata="return zenPage.getContent('data',key,criteria);"
ongetlayout="return zenPage.getContent('layout',key,criteria);"
initialDocumentKey="login"
initialLayoutKey="login"
>
<mojo:jQM-1.4.3-PageManager onPageShow="zenPage.onPageShow(layoutkey,documentkey);">
<mojo:HTML5Helper/>
<mojo:jQM-1.4.3-Helper/>
<mojo:mojoDefaultHelper/>
</mojo:jQM-1.4.3-PageManager>
</mojo:documentView>

Step 2) Implement your logic

I'll just paste the code in here, as I have documented the methods individually:

/// Gets called when a certain layout has been rendered.
/// In this case we are registering additional events and
/// forward them to the onevent callback method in the template.
ClientMethod onPageShow(
    layoutKey,
    documentKey) [ Language = javascript ]
{
    if (layoutKey=='login') {
        zenPage.registerEventHandler('txt-user','keydown');
    }
}

/// Register an event to a layout object by key.
ClientMethod registerEventHandler(
    key,
    eventType) [ Language = javascript ]
{
    var element = zen('mainView').getItemByKey(key);
    element.$findElement('').addEventListener(eventType,new Function('evt','return zenPage.myCustomEventHandler("'+eventType+'","'+key+'");'),false);
}

/// Forward an event to the onevent method in the template.
ClientMethod myCustomEventHandler(
    evtType,
    key) [ Language = javascript ]
{
    var item = zen('mainView').getItemByKey(key);
    var template = zenPage.getTemplate();
    template.onevent(evtType,key,item.$findElement('').value,'mainView');
}

Zen Mojo does not provide a lot of special methods for this task. It involves some coding. 

Herman,

the adaptor approach works for many simple use cases but has issues of its own for more complex scenarios.

If the object graph is huge than the adaptor does a lot of work even if you are only interested in a few properties for some cases.

If you have to serve multiple front-end environments then you have to be able to present an object with multiple levels of details (e.g. native mobile, vs. mobile web vs. desktop web) which require you to do different levels of filtering.

As JSON is more and more used for backend communication as well, you have to be able to produce a verbose JSON output that includes all null values, which are very often omitted for front-ends.

There are many more reasons why you want more control about the projection. We are considering to deliver both approaches: an adaptor class (e.g. %JSON.Adaptor) and a projection method (something like %Compose, but probably with a different name).

Matthew, the system methods (dot-dollar syntax) have been removed in the latest build of the 2016.2 FT. Therefore it is expected that the compiler complains about any .$method you may have in your code.

I am not sure what the issue is with the Macro. Hopefully, Ben can provide more details.