New post
Question
· Jun 20

Replacement for deprecated %ZEN class

#Analytics #ObjectScript #ZEN #InterSystems IRIS BI (DeepSee)

My team and I noticed that the %ZEN class documentation labeled all properties and methods as deprecated.

Example: %ZEN.Auxiliary.altJSONProvider - InterSystems IRIS Data Platform 2024.1 - including private class members

 

In this regard, the big question is: what will be used to replace these methods, in particular %ZEN.Auxiliary.altJSONProvider?

It is used as the basis for the MDX2JSON package, from which DeepSeeWeb gets data to build Analytical Dashboards.

 

Is a replacement proposed for deprecated methods of %ZEN class?

And when is this functionality scheduled to be permanently disabled?

Discussion (20)8
Log in or sign up to continue
Raj Singh · Jul 10

As @Brett Saviano says, if you simply need to work with JSON data, use dynamic objects. If your question is really about the future of data-centric web development with InterSystems, let me step back and offer a higher level viewpoint. %ZEN has been deprecated because it requires some browser features that have been deprecated and may go away at any time. Therefore, we cannot continue to recommend usage to our developers when browsers could break Zen applications and any moment. The DeepSee v3 REST API uses %ZEN classes because it has not been rewritten since the deprecation. 

Zen was developed a long time ago, and many great application development frameworks have gained popularity since then. There are examples of Angular, React, Django and more recently, Streamlit being used in conjunction with IRIS.

There doesn't seem to be a strong desire for offering a proprietary web development framework that could never achieve feature parity with those mass market offerings, and could only beat them in providing faster, more efficient access to the data layer. But I'd love to hear more voices from the community on this topic. 

0 0
Rich Taylor · Jul 11

David,

The issue you will face is that the browser features that Raj has mentioned are core to the ZEN framework.  These features have been deprecated for many years now but have not been removed due applications, such as ZEN, still relying on them.   However, there will come a time where the technical debt of maintaining long deprecated features will become too much.  Its not a matter of if, it is a question of when.   This may not happen for another 10 years or the announcement could come tomorrow.  This ambiquity would certainly make me nervous.  Once one major browser vendor remove these features the rest will quickly follow.

Further attempting to modernize ZEN to work with current web technology would be a quite sizable task and could never hope to reach feature parity with more broadly accepted frame works like Angular and the others listed above.

My advice would be to start looking at which framework best meets your needs (I'm an Angular fan) and begin an effort to convert your screens to that framework and convert any back-end code that needs accessed from the front-end to REST services.  Do this over time converting one module or even sub-module at a time.  Start with several smaller areas so you can gain knowledge and experience.  As you build out your REST services you will undoubtedly discover improvements that would require refactoring previous work.  The smaller modules will make this easier to swallow.

1 0
David Hockenbroch · Jul 11

Rich, I understand all of that. Why, though, do answers to those of us who like Zen always including language like:

". . . could never hope to reach feature parity with more broadly accepted frame works like Angular and the others listed above . . ."

". . . that could never achieve feature parity with those mass market offerings . . ."

I know I'm newer than a lot of people here, but I have yet to see anyone asking about Zen asking for feature parity with any of those other front ends. Meanwhile, the part that actually matters gets discounted:

". . . could only beat them in providing faster, more efficient access to the data layer."

There doesn't seem to be a very good understanding of why some of us are still as attached to Zen as we are (other than momentum). That fast, efficient access to the data layer is extremely important, and we like being able to handle the front end and back end together, seemlessly writing the code it takes to do whatever we need to do on both at once. Zen also allowed us to do all of this using the same skill set that we used for everything else in our projects instead of having to learn two entirely different things for the front and back.

Absolutely none of this has anything to do with a desire for something Zen-like with all the bells and whistles of something like Angular.

3 0
Timothy Leavitt · Jul 12

I strongly relate to this. Zen was a huge part of what sold me on InterSystems tech 15 years ago when I started here as an intern - for all the reasons you've described - and if I want to throw together a really quick POC that just has results of a class query shown in a table, with maybe some basic interactions with the data, I might still use it.

That said, for my team's work and even for my own personal projects, I've found the combination of isc.rest and isc.ipm.js to be *almost* as quick as Zen. With something like Angular with an IRIS back-end (consisting of a bunch of %Persistent classes), you need to write:
1. REST APIs for all your basic CRUD operations, queries, and business logic
2. Client code to call all those REST APIs
3. Client code for all the models used in those REST APIs
4. The actual UI

Suppose you want to make a simple change to one of your models - say, adding a property to a class and making it available in the UI. With Angular, this probably means changes at all four levels; with Zen, you get to skip 1-3 entirely. That's compelling. An inevitable side effect of this is that your application's API surface (and therefore attack surface) is enormous and near-impossible to fully enumerate. It is possible to secure a Zen UI, but much easier to shoot yourself in the foot.

isc.rest makes (1) super easy - add a parent class to your %Persistent class and do a few easy parameter/method overrides to get CRUD and queries basically for free, and write a bit of XML if you want to do fancier things to expose business logic or class queries. This provides enough metadata to generate an OpenAPI spec, which can then be used to automate (2) and (3) with the help of openapi-generator. So while you can't skip 1-3 entirely, this toolset makes it all significantly faster.

4 0
Evgeny Shvarov · Jul 13

Hi Tim!

A few questions on isc.rest.

1. What is the format of version:  <Version>1.2.2+snapshot</Version>?  

2. Does it relate to unit tests <Resource Name="/internal/testing/unit_tests/">
          <Attribute Name="Package">UnitTest.isc.rest</Attribute>? 

is it callable by zpm "test isc.rest"? 

3. Lifescycle class - is it mandatory for every package? It looks very complicated what is going on there. Why not use <INVOKE>?

4. Defaults:

What is this for? is it mandatory?

<Defaults>
        <ProcessorDefault Class="Default.Include">
          <Attribute Name="Format">UDL</Attribute>
        </ProcessorDefault>
        <ProcessorDefault Class="Default.Class">
          <Attribute Name="FilenameExtension">cls</Attribute>
          <Attribute Name="Format">UDL</Attribute>
        </ProcessorDefault>
        <ProcessorDefault Class="Default.Package">
          <Attribute Name="FilenameExtension">cls</Attribute>
          <Attribute Name="Format">UDL</Attribute>
        </ProcessorDefault>
        <ProcessorDefault Class="UnitTest">
          <Attribute Name="Format">UDL</Attribute>
        </ProcessorDefault>
      </Defaults>
0 0
Dmitry Maslennikov · Jul 11

I see that the best solution would be if InterSystems would make this package available as an open source, with an option to upgrade any existing instance with the open-source version by using IPM for instance

In this case, any team that keeps using ZEN may provide their thoughts on how the modern ZEN should look in the form of PullRequests. There would be a place to post bugs and feature requests, which some community members may help to solve for everyone.

3 0
Rob Tweed · Jul 12

Zen users needing alternative solutions may find some of our (MGateway) technologies useful.  EWD has been around for longer than Zen and is still an actively-supported product that is used by some extremely large Cache/IRIS users.  Contact me if interested.

Alternatively you can take a look here for our latest high-performance back-end integration technologies for IRIS, and also our glsdb JSON abstraction for JavaScript/Node.js (and Bun.js) which may provide a useful (and very simple yet effective) solution for your JSON needs:

https://github.com/robtweed/mg-showcase

You'll see our range of solutions summarised on our web site at www.mgateway.com

1 0