Out with the Old, In with the Old, Building your Domino Web Application using DX Objects

Building a Web application on HCL Domino can be challenging because there are so many ways of creating a Web application. There is just no design pattern to follow or best practices.  This is good for us who like to experiment, but bad for developers who just want to follow an official approach.  You can use XPages, classic Domino Web with Pages, computing fields and computed text with formula language or you can create apps using REST APIs with LotusScript, Java , DAS (please no) , view read entries or even DRAPI as Paul Withers has demonstrated on his blog, https://paulswithers.github.io/blog/2024/08/15/xpages-web-1/

However, there is little talked about a very old technique that dates back to the beginnings when Domino became web enabled.  As part of my data visualization session demo at Engage 2025, I used this technique to generate the web pages and dashboards.  

This technique allows you to separate the form, data and business logic and creates a standardize design pattern for one to build web applications. XPages is the only other approach that comes close in enforcing a design pattern.

So what is this technique? A few years ago, I was looking for a way to create a blog for our web site that we had full control. Our Wordpress site was hacked even before we were finished because of vulnerabilities in plug-ins and later it was discovered that the large hosting company did not properly secure passwords. Go figure. But all too familiar.

I attempted to use the Domino Blog template as a replacement.  However, trying to modify the Domino blog template was a journey of frustration and a series of futile actions. I truly believe in the separation of form, data and business logic and the Domino Blog template is another example to the contrary. As I dug deeper into the code there was a technique in generating web pages that I had not seen or hear of before.  

I coined the phrase DX Objects for this technique. The approach is quite simple but powerful. Each web page is represented by a Web Navigator/Form pair that forms together as a Web page container.  Located in each form is a Rich Text Field called html along with other CGI fields that you want to include. Put these all into a sub form.

The WebQueryOpen (buildWebPage) agent in the form is triggered when the user navigates to the Web page that has the corresponding name of the navigator.

The buildWebPage agent reads from a rich text field in a document with the html that you want to generate and display the web content. The document doesn't have to be in the same database. This allows you to secure the content and not allow web access.  

For static web pages that is all you have to do. But more interesting is to use the concept that is found in the Domino Blog template that allows you to add complex business logic in building the web content, DX tag markups with the format of <$DX(something)$>.  Now you can use any mark up you want, but for the demo I used the standard DX markup found in the template.

The goal is to replace the DX markup with business logic that you need and output the response to be included in the html generation of the Web page.  The response could be html, text, JSON or others.  That depends on your need.  

In our example below we have the <$DX(CurrentYear)$> and it calls a LotusScript function that returns the current year.  That is simple enough, that you can do with computed text in a Domino Page.  However, what happens when you need to return a response that needs to lookup data even on a different server, process the data based on a variety of criterions. It maybe possible with formula language, but most likely not.  In addition, you are still limited to 32K.

You can even use it to generate fetch calls to REST APIs to get data or info during the onload process.  

And here is the results of demo01 page.

The advantages of creating your web page with DX Objects are:

• Integration to more up-to-date Dojo/custom widgets or widgets created with React, Vue or other frameworks
• HTML output that inhere to HTML 5 standards
• Incorporate complex business logic
• Add better access control for REST API based applications
• The web content can easily excess the 32K limitations

For us at Phora Group, we have more advanced features that utilizes our LotusScript Flex Parser and our LotusScript HTML Parser to provide what we need for iPhora.  However, there is no limit on what you can do. Only your imagination limits you.  You don't have the crazy 32K limitation of computed text and other restrictions.

Performance wise the web page generation is in par with other approaches. It depends on the complexity of your business logic, but also how you get the content.  If you are using a lazy load approach to retrieve your data, then the web generation will be extremely fast.

You can get the sample Engage 2025 databases that I created from my previous post.

https://dominointerface.blogspot.com/2025/06/engage-2025-visualize-your-domino-data.html

As a follow up to this post, next time we will cover how to have basic VS Code integration with Domino and create the HTML, JavaScript, and CSS all using VS Code and have it pushed into Domino.