Hi Lucas,

I suggest you open a WRC case with Support so that we can look into the details of what is happening here. This may be a problem specific to the environment.



Hi Jules,

which Perl distribution are you using? We do support the ActiveState Perl distribution. Also, ensure that you are using a bitness version that matches the bitness of your Caché instance (64-bit in your case).



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()
        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();




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:

ongetdata="return zenPage.getContent('data',key,criteria);"
ongetlayout="return zenPage.getContent('layout',key,criteria);"
<mojo:jQM-1.4.3-PageManager onPageShow="zenPage.onPageShow(layoutkey,documentkey);">

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(
    documentKey) [ Language = javascript ]
    if (layoutKey=='login') {

/// Register an event to a layout object by key.
ClientMethod registerEventHandler(
    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(
    key) [ Language = javascript ]
    var item = zen('mainView').getItemByKey(key);
    var template = zenPage.getTemplate();

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

Whether you should be using the default transport layer of Zen and Zen Mojo or built your own REST interface depends on a couple of things:

  1. Your skill set and your development resources
  2. The size of your application
  3. How many different front-end interfaces you have to serve

If you have to serve multiple front-ends, e.g. a native mobile app, a web app and some data to a reporting layer then a REST interface makes you more flexible to actually meet the data needs of each of them without duplicating too much code.

If you just want to get your Zen/Zen Mojo application working without too much extra learning, the standard transport way is just fine.

In general REST interfaces are just a clean way to build your communication layer. If you make your REST calls in the Zen Mojo onGetContent method you will still get the benefits of client-side caching within Zen Mojo. The only real difference is that your data retrieval code now lives in a separate class (a subclass of %CSP.REST) instead of a Zen Mojo template.  

REST interfaces are indeed easier to test and debug as they can be tested by tools. The Zen / Zen Mojo client/server communication requires some knowledge if you really want to know what is going on.



I haven't dealt with SSEs yet, but I can say that WebSockets work like a charm. 

SSEs are not using a special protocol, they work within the HTTP specification and are build on the server by setting the "Content-Type" header to "text/event-stream". From my understanding, this can be easily implemented with a CSP page. 

The reasons why SSEs are not as popular as WebSockets are:

SSEs have some interesting advantages over WS like the use of a simpler protocol, automatic reconnection, and event IDs.

Hi Fabio,

yes, in theory, there is a way how you can load other templates, but I do not encourage this approach as loading a template can be expensive.

It is better to use one of the following two approaches:

1) Generic utility functions should be placed in a javascript file that can be included

2) You can also build a base template that includes your utility functions and let your other template subclass the base template.

The second approach makes sense if it is unlikely that a given template that requires these utility functions will be loaded and you want to save the footprint. Otherwise, I would always stick to option 1.

I haven't done this before, but I am pretty sure you have to call %Save in order to apply your changes.