New post
AllAccepted answers
Stefan Wittmann · Aug 29, 2016

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.

HTH,

Stefan

Stefan Wittmann · Aug 29, 2016

Hi Ward,

you can contact WRC to get access to the proper 4.x version.

We've made some progress on the npm release, but it will take us more time until we can actually upload the modules to the repository. I will make an announcement here once the node modules are available via npm. 

Stefan Wittmann · Aug 25, 2016

Steve,

the onevent callback is used for events like viewport adjustments and you should call this method for your custom event handlers.

Zen Mojo does not register to all possible events on a page in order to throw them at onevent. Page performance would be horrible. If you are interested in any additional events, like onkeydown, you have to register them in addition.

HTH,

Stefan

Stefan Wittmann · Aug 22, 2016

Try passing in the stream object. You are operating on a string, that is why you are getting MAXSTRING errors. This should work:

TRY
{
Set RequestObj = ##class(%Object).$fromJSON(%request.Content)
} CATCH(Exception) {
Set Status=Exception.AsStatus()
}
Stefan Wittmann · Aug 3, 2016

I am aware of the situation and we are working on publishing the node.js versions via npm independent from Caché kits. While that may take us a while, you can request the latest versions of the node.js module from WRC.

Stefan Wittmann · Jul 28, 2016

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.

Stefan Wittmann · Jul 19, 2016

SPAs can work with the browser back and forward button if the URL is updated and the page is pushed to the history stack.  The page Eduard refers to actually mentions this. The jQuery Mobile plugins do implement and support this, you can verify this by opening

/csp/samples/ZMdemo.jQM145.HomePage.cls?

in your browser (point it to your local instance) and play with it.

Currently, our Bootstrap plugin implementation does not support this, because we only implemented a helper plugin and not a page manager. Page managers are responsible for the overall behavior of the SPA.

Stefan Wittmann · Jul 19, 2016

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.

Stefan Wittmann · Jul 15, 2016

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

Stefan Wittmann · Jul 15, 2016

As Kyle mentioned your code should be:

<button caption="Save" onselect="zenPage.saveRecord();" />

It appears the section Lisa linked to is not correctly displaying onselect multiple times.