go to post 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:Your skill set and your development resourcesThe size of your applicationHow many different front-end interfaces you have to serveIf 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
go to post 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.
go to post 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
go to post 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() }
go to post 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.
go to post 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:a WS is bidirectionalWS 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.
go to post 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.
go to post 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 included2) 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.
go to post 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.
go to post 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.
go to post Stefan Wittmann · Jul 12, 2016 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.
go to post Stefan Wittmann · Jul 8, 2016 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')
go to post Stefan Wittmann · Jul 4, 2016 Kevin, the parser in Atelier should indicate no error here. Updating the Studio parser has a low priority as Atelier is the path forward for the IDE. If you see an issue with Atelier, please let us know. Many thanks.
go to post Stefan Wittmann · Jun 22, 2016 Yes. The SQL page in the System Management Portal just sends the queries to the Caché server for execution. So every query that is supported by the server will run there.
go to post Stefan Wittmann · Jun 22, 2016 These two SQL functions are new in Caché 2016.2. Just grab the field test to take a look at them.I will update the article to include the version, as I have obviously missed this.
go to post Stefan Wittmann · Jun 21, 2016 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.
go to post Stefan Wittmann · Jun 16, 2016 Hi Jan,in case you haven't done this yet, please contact WRC directly for your node module request. http://www.intersystems.com/services-support/worldwide-response-center/
go to post Stefan Wittmann · Jun 15, 2016 You can index any property within a document and by default, we will construct a bitmap index, but all index types supported by Caché Objects are supported by the document data model as well. So yes, we do support indexing a nested path within a document.I am always happy for a constructive discussion and to learn about different viewpoints. In the end, we all have a better understanding and can build better products and applications.
go to post Stefan Wittmann · Jun 9, 2016 Hi Danny,great to see you here.The standard credentials you can use on a new system are _SYSTEM / SYS. You can manage the users in the management portal later on.
go to post Stefan Wittmann · Jun 9, 2016 Chris,we are currently working on REST discovery and documentation, so expect more in the future. Currently, your best option is to manually document your URI paths. Personally, I find Swagger a very good tool to document REST endpoints as it also allows you to test interfaces and to generate clients for multiple languages.
