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.
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.
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).
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.
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)XEP for .NET does support both in-memory and TCP/IP connections. The client must be on the same machine for in-memory connections but can run remotely for TCP/IP connections. Long-term we will move away from in-process connections, but we haven't taken this step yet for XEP for .NET.
We consider support for .NET Core interesting and are currently evaluating support for it. But it is too premature to promise anything yet.
Indeed underscore characters are fully supported in the new JSON API (%DynamicObject and %DynamicArray). Are you sure this is the only change you made?
I also advice to use a local mailserver, which eases configuration and testing. A popular example is PaperCut:
https://github.com/changemakerstudios/papercut
It is much easier to spot configuration issues as you can take a look at the mailserver logs as well.
HTH,
Stefan
I am not sure if I got the question right. If you already have a Zen or Zen Mojo application and would like to add a login page, I strongly recommend to develop the login page as a separate CSP/ZEN or Zen Mojo page. From my experience Zen Mojo is too heavy just to build a single simple login page (as it is designed for a complete SPA - single page application), so CSP or ZEN is recommended.
If you are starting from scratch I usually recommend to pick a modern framework like Angular you feel comfortable with and communicate via JSON/REST to the backend.
Responsiveness is usually achieved by a mix of picking UI libraries that are responsive by default (e.g. Bootstrap) and your own responsive CSS implementation.
If you require a native application for mobile devices on iOS and Android (e.g. to interact with the camera) you have to be a bit more specific. But your options are either a native application (Swift or Java) or a hybrid (e.g. via Cordova or Ionic). The communication channel always is JSON/REST, so you have to start by designing your REST interface first, no matter what your web client looks like. At least for the majority of the use cases.
Please let me know if you require additional information.
HTH,
Stefan
Glad to hear you were able to make it work. Debugging these issues can be really painful. Emulators help as you can easily work with the debugger, but emulators only tell you half the story...
I usually debugged and tested these scenarios on a real device, connected to the IDE on my laptop, which allows you to see exactly what is going on via the output window and the debugger of your IDE.
Hi Arto, the enhancements mentioned in my post are specific to IRIS.
Hi Juha,
IAM is only available in container format and we have no plans to change that at this point in time. I would like to understand the background of your question. Would you prefer a regular installer and if so, why?
Thanks,
Stefan
I updated the announcement adding a link to the technical introduction which I just published. Enjoy! :)
Alexander has provided the correct answer, you have to unpack the archive first. The reason is that the IAM distribution includes more than just a docker image, but also a readme file and various scripts to make your life easier. That's the reason why the WRC Distribution page lists IAM in the components section and not together with the other containers (like ICM).
Yes. The first release of InterSystems IRIS that supports IAM and is available on all platforms is 2019.1.1.
No, it is not for multiple reasons. We have plans to publish the InterSystems API Manager on Docker Repositories at a later point, but I can't give you an ETA.
The error means that the version of your Java runtime is too old. For more information on this error, please see a related stackoverflow thread:
http://stackoverflow.com/questions/10382929/how-to-fix-unsupported-majo…
Recent versions of Caché and Ensemble only support Java 7 and 8, as Java 6 has reached end-of-life and has multiple security flaws.
Upgrade your Java runtime to 7 or 8 and the error will go away.
There is no easy way to achieve this on the server side. But you can easily extract the currently displayed data set on the client. Here is a code snippet that works with the tablePane demo ZENTest.TableTest.cls in the SAMPLES namespace:
var t = zen('table')
for (var i = 0;i < t.pageSize; i++) { console.log(t.getRenderedRowData(i)) }The code snippet will render each individual row, respecting the current filtering and order.
Mike, you can favorite a post and later on you can find them again under "My content -> my favorites". Does that help?
I am not sure if this helps, but I want to mention that Ensemble comes with an option to export all classes and routines that are required to run an Ensemble production. At least, all dependencies Ensemble can resolve.
You can find the related documentation here:
http://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY…
Maybe you can take a look at the code behind the scenes, or analyze the output of such an export.
As the others, I am trying to guess what you mean when you say organizing code. I can think if source control, project organization and auto code formatting.
If you get more specific we can provide a better answer. If you are not aware of Atelier, our new Eclipse-based IDE, take a look at the session recording from Global Summit 2016:
https://beta.learning.intersystems.com/mod/page/view.php?id=212
Jochen's approach is one way of dealing with this scenario. Another approach is to always inject the header and footer layout and drive the content with a data binding. This way you can always include your generic header/footer layout objects in all of your pages. This approach also allows you to implement your header and footer logic in a central method, so you don't duplicate code.
If you want more sophisticated control, you can easily build your own plugin and implement your own header/footer components with specialized logic and behavior.
Not in the near-term. We are using a highly optimized in-memory and on-disk structure for our JSON support and the document data model. Providing more features and adding more optimizations to this structure stays a priority.
Our model allows us to support other serialization formats as well and we have some hooks in place we plan to leverage in the future. MessagePack and other serializations are on the tentative list for this, but nothing is carved in stone at the moment.
Do you have a specific use case where MessagePack is a requirement?
Hm, interesting. So what this basically means is that the 404 page gets cached when a URL is requested and it is not available. Re-enabling the REST application does not clear that cache and that is the reason why the REST application does not work for the URLs that have the 404 cached when it's enabled again.
Automatically clearing the cache for a REST application is not trivial, as it does not translate to a single URL. I will check back with the developers and see what we can do about this.
If it is more complex to determine the data set, because you have specific parameters in mind it makes sense to select the data via SQL and insert the selected record into the other instance via SQL. You can either use linked tables, which allows you to write this simple logic in Caché Object Script, or you can write a simple Java application and go directly via JDBC. Obviously, any supported client-side language can solve this challenge, Java is just one option.
In case you have to migrate data where the model includes foreign-key constraints, you have to use the %NOCHECK keyword in your SQL INSERT statement: http://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY…
This approach is definitely more work than just exporting/importing the data, but it allows to easily add simple logic with some benefits, e.g. anonymization, batch-loading and parallelization. Depending on your use case some of these topics may be relevant.
Alexandre, which layout object from which plugin are you using?
Steve, you've included the jQuery library twice. Only import the latest release of jQuery and you should be fine. If not, let us know.
Also, make sure that the bit versions of Atelier and your Java installation do match (both 32-bit or 64-bit). Here is a detailed explanation what this error means and how to resolve it:
http://www.ashout.com/fix-java-started-returned-exit-code13-eclipse/