Don Mottolo makes a good point in his comment on my recent blog post, that there are aspects of other web frameworks that make it a non-trivial task. This is also really why some people talking about Domino are talking about “mid coders” and “pro coders”. And it’s also why the terms don’t really exist outside the yellow bubble.
One of those areas is state management.
Let’s consider state management in Notes Client. For some years there has been a preference to re-open tabs that you had open the last time you closed the Notes Client. This is an example of state management – your Notes Client retains the state that existed last time you closed Notes. Another is views. When you go to a view, you are at the position of the last document you worked on. Edit and save a document, and again the same document is highlighted, as long as the changes made haven’t removed it from the view.
There is a state store available to you, if you wish. You’ve probably used it without realising that’s what it is. That is notes.ini environment variables. I’ve used it extensively lately for Domino Mobile Apps development. It is basically the equivalent of sessionScope in XPages.
Global variables may be used on a Form for persisting values between various actions. And as I blogged about recently, the “static” keyword in LotusScript also allows you to persist variables between calls to a function.
But on the whole, in Notes Client development, state management is something we just ignore.
When XPages came along, it also handled a lot of state for us, again without us realising that’s what was happening. State is persisted across component code by “requestScope”, across the life of a page with “viewScope”, across a browser session within the NSF by “sessionScope” and across all sessions for the NSF with “applicationScope”.
There’s also something called the “component tree”. This is where the structure and existing state of an XPage and its Custom Controls is stored – either in memory or on disk, depending on Xsp Properties’ Persistence Settings. Many may not realise, but viewScope is also stored or persisted in the component tree.
But the fact is, this is all hidden from developers and the XPages runtime does it for you. If it didn’t, you would need to make a programmatic call to write viewScope to memory/disk, to write components with their current property values to memory/disk.
Removal of the persistence is also handled automatically for you. You don’t need to make a call to unload an application or session from memory after a certain time or remove the nth component tree. You set properties in Xsp Properties’ Persistence Settings and the XPages runtime handles it all for you.
We first had to handle state ourselves with views, before the Extension Library. If you opened a document and went back to the view, you went back to the first document. There was nothing in-built to go back to the same document, or have everything expanded that was previously expanded. And many developers struggled with that and required something to “Just Do It For You”. That’s why we got the Pager Save State control. And again, developers probably didn’t stop to think what it was doing and how they might build that themselves elsewhere.
The other aspect is when state is persisted. XPages offered great flexibility, with virtually everything being computable. So state tends to be coded on the components themselves. We compute the “rendered” property on the component itself. We don’t update the “rendered” property from the business logic, by getting a handle on the component from outside and calling setRendered(false).
Beyond Domino – Vaadin
First, I should say that I haven’t developed with Vaadin for some time and there have been a number of releases since I last did anything.
Vaadin is a full Java web development framework. Everything is coded in Java, typically with controller classes and “custom controls” (basically a component containing multiple other components – buttons, inputs etc). The components are created in Java, the page built up with Java, and handlers (button click, etc) change properties on components by getting a handle on them and updating them.
This is the key different to XPages. Instead of re-calculating all components’ properties during a page update, it just updates editable values changed in the browser, runs converters and validators, and runs business logic at the point of interaction by the user (e.g. a button click). It’s the business logic that manipulates the properties.
Apart from that the way it handles state has a lot of similarities to XPages. That’s probably not a big surprise, after all they’re both frameworks building on Java servlet technology. But the big difference is that Vaadin apps are coded fully in Java as a standard web application developers whereas XPages applications are built in an NSF with an application navigator that hides the web application structure. And the state management is accessed via classes that have the word “servlet” in their name, not variable names that hide how the state management is done, to simplify it for new non-Java developers. Because of where the developers are coming from and the necessity for simplification of standard technologies, Vaadin developers are probably more aware of what’s happening under the hood.
Beyond Domino – React
If you understand what needs to happen in state management, it’s a learning curve but manageable. If you’ve isolated yourself from that in Notes and XPages, it’s a massive mind-shift, as Don says.
And there are other aspects that complicate it further, which I’ll come into.
Beyond Domino – Node-RED
Node-RED has state management as well. But to some extent, as a mid-code environment, it does a lot of simplification. There is the msg object that runs through a set of nodes. There are the flow and global objects that share variables across a flow / sub flow and between flows. Similarly, there are config nodes, that store information and are used by multiple nodes. But state is typically dumped if Node-RED restarts.
There is a storage API that can be used to persist state more widely, but that’s something you have to code yourself.
If you’re not using that, state is much more similar to XPages scopes. The flow and global objects are JSON objects, which are effectively the same as the Java maps sessionScope etc. And there is another key similarity that I’ll come back to.
Don is correct that there is a lot of complexity outside of Notes and XPages. The big change is needing to understand at a much lower level what’s going on. And we’ll see that again in my next blog post.