In what may be the last in this series for a bit, I'll talk about the current approach I'm taking for the UI for the new OpenNTF web site. This post will also tread ground I've covered before, when talking about the Jakarta MVC framework and JSP, but it never hurts to reinforce the pertinent aspects.

In deciding how to kick off implementation specifics of my new OpenNTF site project, I had a few options, and none of them perfect. I considered starting with the managed beans via CDI, but most of those are actually either UI support beans or interact primarily with other components. I ended up deciding to talk a bit about the REST services in the app, since those are both an extremely-common task to perform in XPages and one where the JEE project runs laps around what you get by default from Domino.

The design for the OpenNTF home page has been with us for a little while now and has served us pretty well. It looks good and covers the bases it needs to. However, it's getting a little long in the tooth and, more importantly, doesn't cover some capabilities that we're thinking of adding.

A few versions ago, I added Jakarta NoSQL support to the XPages Jakarta EE Support project. For that, I used DQL and QueryResultsProcessor exclusively, since it's a near-exact match for the way JNoSQL normally goes things and QRP brought the setup into the realm of "good enough for the normal case". However, as I've been working on a project that puts this to use, the limitations have started to hold me back.

At Engage 2022 Volt MX Go was announced including features like Volt Formula, a JavaScript-based fusion of Notes formula syntax and Open Formula, and VoltScript, a derivative from LotusScript, and inspired by many modern implementations of BASIC, which will run in Foundry, Volt MX Go’s middleware layer. Already at Engage we demonstrated live running code of VoltScript with Try/Catch/Finally, an alternative declaration keyword “Def” for “Dim” and deprecation of GoSub; which let’s be honest is Satan’s spawn. These are the first changes to the core LotusScript language keywords in over 30 years. In addition, we showed live demos of code running triggered from Foundry as well as standalone VoltScript outside of HCL Notes or Domino, for the first time since the end of life of Lotus 1-2-3. We also showed a number of new extensions (LSXs / VSXs) that will obviously be required, as well as developer productivity tooling like unit testing, mocking and a POC of dependency management.

Case insensitive deserialization - Growing up in Windows with BASIC you learn case doesn't matter, so Color is the same as COLOR or cOLOR when it comes to variable names. Same applies to @Formula or item names in Notes documents. On the other side, Linux, Java, JavaScript and JSON are very much case sensitive. This poses a challenge when deserializing (handcrafted) JSON files.

Today we released version 0.9.48 of Domino JNA as OSGi plugin for XPages developers and on Maven Central. Here is a list of new features: API to read and write the Notes workspace (read, create and modify pages and icons, change page order, move replicas on top etc.) Formula execution now supports more than 64k of return data API to apply security to formula execution (e.g. prevent Notes.ini changes) API for QueryResultsProcessor (produces JSON and views) Java 8 date/time support for NotesNote.replaceItemValue(...) New utility class to format view data as markdown table Added method to get agent design doc UNID Added hierarchical recycling (parent/child auto recycle)