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.

Regards,

Stefan

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).

HTH,

Stefan

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

Hi Jiri,

take a look at this part of the documentation:

http://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY…

I recommend using a code structure as described in example 1 (try-catch).

HTH,

Stefan

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. 

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:

• a WS is bidirectional
• WS are supported by all major browsers, while SSEs are not supported by IE and Edge (http://caniuse.com/#search=server-sent%20event)

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.

Hi Simcha,

the best way to leverage this widget is to build your own bootstrap dual listbox plugin. Take a look at the code of the other plugins and make sure to check the documentation for creating helper plugins before you start:

http://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY…

Let us know if you encounter any difficulties.

N.B.: I should mention that you can also just create the proper HTML code in your layout, but then you have to manually call the initialization and refresh methods in your application code all the time.

The document ID is exposed implicitly as a virtual column named "_documentID". Here is a simple example that you can run in your SAMPLES namespace:

SELECT _documentID, Name, DOB, SSN FROM JSON_TABLE('People','$' %TYPE 'Sample.Document.People')

Hi Chris,

unfortunately, the information in the Caché Technology Guide that you refer to is outdated. We do support JPA (Java Persistence API) via Hibernate and are currently in the process of updating our dialect. We provide no special tooling for EclipseLink.

I will make sure that the information on the website is updated.