The iPhora Journey - Part 3 - Creating an Integrated UI Framework

The iPhora Journey - Part 1 - Reimagining Domino

The iPhora Journey - Part 2 - Domino, the Little Engine that Could

The iPhora Journey - Part 3 - Creating an Integrated UI Framework

There are many ways to create the user interface (UI) for a web application. The HTML page could be created on the server and then pushed out. It could be static with the data generated on the page by the server with JavaScript, providing a more dynamic experience, or the server could generate new HTML content to update portions of the web page. XPages or PHP are good examples of this. Another method is to have the web page partially generated by the server and have JavaScript build the rest of the HTML by pulling data from the server via an API. This is the approach used in the Single Page Application (SPA) model.

In all cases, it is still dependent on the web server technology being using.  As mentioned previously in this blog, XPages is dependent on complete integration between form and document, which effectively results in tight integration between form/UI/data.  This close coupling limits the flexibility on both the server side and client side.

With its long history, Domino has gone through a number ownership changes. Before HCL Technologies acquired Domino from IBM, the future of Domino was somewhat in doubt, and during that time, we felt it was necessary to have the ability to switch to a different server platform if Domino was no longer an option. Therefore, we concluded that our UI framework had to be totally independent of server technology. We focused on a pure JavaScript-generated UI framework that only existed in memory and utilized a single HTML container. The layout, navigation, display, updates etc. would all be driven by API requests and responses to the server.

With this approach, it does not matter how the APIs are created or what server technology is being used. Currently, we implement APIs with LotusScript Web agents, which are one of the most secure ways to generate data and communicate with web clients on Domino. However, we can also also switch to APIs that are created using Java or Node. All that matters is that the API framework and structure are consistent. A loosely coupled platform allows for an easier upgrade process, as individual components can be upgraded separately, and provides increased portability. It also allows the back-end team to focus on the business logic running on the server and the front-end team of UI designers to focus on the interface. This also means that the front-end team needs minimal, if any, knowledge of Domino, which greatly expands the talent pool for hiring UI professionals.

This approach evolved into our SPA framework, which initially used a single XPage as an HTML container. We eventually determined that there was no advantage to having it as a single XPage and moved it to a single Domino Page, which did not have all the overhead associated with XPages.

An IBM Business Partner once asked us what would happen to our investment in our framework if we were forced to change server technologies?  And the answer was nothing, except for minimal changes to the API routing table. 

So, how did we create this UI framework?

The Rise of UXPages

So, 13 years ago, we created UXPages almost as a parody of XPages. It started as a playful experiment to see if we could come up with something to replace XPages. Like XPages, we wanted an XML representation of the interface, but rather than compile to Java, it would compile to JavaScript. Since we are somewhat lazy and do not want to manually write JavaScript code, we sought a more automatic way of generating code, including support for versioning. We also wanted to avoid the use of Domino Designer to create and edit the code.

Thus, the iPhora Application Designer was born. It was a Notes client application that was written in LotusScript. It compiled the UXPages XML into JavaScript, and via the magic of DXL, it pushed the JavaScript into the Domino server, never having to open Domino Designer. We even incorporated Nodejs so that we could utilize Uglify (which may be the worst name for a JS library in history) to minimize the JavaScript. However, we did not want to write a JavaScript framework from scratch. Our starting point was Dojo, which was already included with Domino. But after researching how Dojo was implemented in XPages, we decided that it would be better do use Dojo on its own and not the version that was included with XPages.

Unlike JQuery, which is another JavaScript library, Dojo was the first true JavaScript framework. Before ES6 came along, Dojo already supported super classes, classes, inheritance, modules, etc. As a framework, Dojo provides a complete architecture for building widgets, including widget lifecycle management. But standard Dojo widgets, like the ones currently used in XPages, are rather ugly. So, we decided to build all of the widgets from scratch and not utilize any of the existing Dojo widgets. But then how would we make our new widgets beautiful and appealing? We settled on the CSS framework Bootstrap, which was developed by Twitter. In doing so, we avoided using any of the Bootstrap widgets, since they were based on JQuery. Instead, our widgets had to bind with the incoming data from an API request.

As we progressed in our widget development, we realized that we could extend the use of using widgets to handle views, panes, and other features of the application. As a result, our SPA application is just a multi-layer sets of widgets, where each layer inherits from its parent widget. The concept of widget lifecycle was extremely important. As a user navigates between virtual pages, new widgets, view, and panes are created and old ones destroyed in order to avoid consuming an ever-increasing amount of memory.

It is true that many in the industry have moved on to other libraries, such as Vue, React and NextJS. However, having long term support and longevity should not be underestimated. We already have applications running on UXPages that are close to a decade old. Also, the integration and use of Dojo within XPages really gave it a bad reputation, at least within the Domino community. However, it should be noted that even in the latest version of XPages, the version of Dojo is extremely out of date (currently, it is eight versions behind the latest version). When the current version of Dojo is used as we use, it is capable of generating a modern and engaging UI experience.

As UXPages evolved, we added data binding with the APIs, utilized newer ES6 features of JavaScript, and added listeners/broadcasters to widgets so they can talk to each other and exchange data. The evolution is still continuing. So, what's next for UXPages? Possibly, PWA capabilities and more. However, for now the components that made up iPhora Application Designer form the foundation of our No-code/Low-code iPhora AppBuilder product, which will be described in a future blog entry in this series.

Next time, The iPhora Journey - Part 4 - JSON is King

The iPhora Journey - Part 3 - Creating an Integrated UI Framework

The iPhora Journey - Part 2 - Domino, the Little Engine that Could

The iPhora Journey - Part 1 - Reimagining Domino