From XPages to Web App: Introduction

Table of Contents
Introduction
Part One – The Application
Part Two – XPages Advanced 1
Part Three: XPages Advanced Database Separation
Part Four: XPages Advanced Document Wrapper
Part Five: XPages Advanced MVC Controller
Part Six: Use of OpenNTF Domino API
Part Seven: OSGi Application Development Introduction
Part Eight: OSGi JAX-RS REST Access with ODA
Part Nine: OsgiWorlds
Part Ten: Vaadin
Part Eleven: OsgiWorlds Document Wrapper
Part Twelve: Key Date Page
Part Thirteen: Application Structure
Part Fourteen: Calendar View
Glossary

One of the biggest takeaways from IBM ConnectED in January was how many people who have travelled down the XPages route had moved from being a Notes developer to a web developer. I’m one of those. I did some Domino web development, but it was an arcane skill, with a lot of hacks. If you wanted to use standard web development frameworks or methodologies, the standard ways of implementing them often didn’t work and you needed to use workarounds. I encountered this when adding Dojo to a standard Domino web application, which I would not have attempted without a project called Dojomino. And when implementing workarounds for standard frameworks on proprietary platforms, the problem, as ever, is the limited knowledge base you can draw upon when you hit a problem.

Back in 2009 when I first started learning XPages, the vast majority of my work was on Notes Client applications. It was a strong platform for software development. Many Domino customers still heavily investing in their applications. Network speeds and browsers often limiting factors for affordable web development alternatives. The main competition to Domino as a storage mechanism was relational databases, other NoSQL alternatives and graph databases were not prevalent in enterprise customers. Cloud SaaS offerings were few. Few enterprise applications were mobile-enabled and “mobile first” was not a development strategy for companies. And Domino had a strong position as “middle-ware”, either integrating disparate non-Domino data into a single UI or acting as a “staging area” for custom workflows for data sucked from and subsequently pushed back into none-Domino ERPs.

In the subsequent years, many customers cut back on their Domino maintenance, their development teams and their development spend (a big reason for the reduction in customers attending user group events). Moving applications to the web and mobile became a popular approach. Many customers started looking to use cloud offerings for things like CRM systems or trying to replace Domino applications with modules of ERPs they were implementing. And I fear the number of “spreadsheet applications” has increased as a result. In terms of database competition, other NoSQL options have become “cooler”. And although XPages has offered a lot, it’s equally fair to say that Domino and Notes have suffered from historical technological constraints: the Eclipse container is woefully out of date now; the inextricable coupling of Notes and Designer means developers cannot take advantage of the latest editors easily; the HTTP and servlet engines are old; authentication options are limited (oAuth cannot easily be integrated, for example). Basically, the development landscape has changed significantly over the last six years and, particularly when you look at Bluemix, it highlights the breadth of options available and puts XPages, Domino and Rich Client Platforms in context.

But it’s not all doom and gloom. Nor am I advocating dumping Domino and doing a custom redevelopment on another platform entirely. I’m not in a position to speak with authority on off-the-shelf migration solutions, but the styles of coding, quality and complexity of the applications I’ve built over fifteen years’ worth of experience varies greatly; so I would expect some degree of compromise of functionality, regardless of an assessment about whether all the functionality is still appropriate for migration or fit for purpose. But for a Domino developer to dump years of experience and start developing standard web applications with a non-Domino backend is fraught with risk. End users want the applications they want, they will not agree to a basic spec to allow the developer to get to grips with the basics, adding more sophisticated functionality at a later date. End users also tend to want a user experience they’re familiar with and developers tend to want a development experience they’re familiar with, evidenced by the amount of XPages questions on StackOverflow asking how to provide a Notes-client-style experience in an XPages application, rather than looking to give a web-application-style experience. And even if you can redevelop your application, with a user experience appropriate for the new technology, there’s still the data. Sales people often sell the new solution and fudge questions about data migration, and for a very good reason – it’s a significant cost. Enterprises rarely account for the cost of the migration, even if they have the skills to estimate the cost. Even with something as “standard” as mail, migration is not straightforward. So how can you expect it to be for a custom application? Particularly if moving from a NoSQL datastore to relational, and even without the question of “rich text”. If the users don’t need data migration, it’s fine. If they do need data migration, they may still not get it, resulting in either manual transfer of data or dual running. Furthermore, timeframes are worth bearing in mind: redevelopment of an application rarely happens in the timeframes vaunted at the start of the project.

So if redeveloping the application is required, and a modern web development framework is preferred, maybe it’s worth keeping the data where it is. Users are often dissatisfied with Domino not because of the backend, but because the UI that’s available looks and feels dated (and if IT have not invested in the application, blame IT not the platform!). Where performance is slow, timely archiving has often not been implemented or optimisation has not taken place. In many cases, the backend is fit for purpose for the data and the developer is more than comfortable with programmatically interacting with the data, indexing the data, authenticating, sending emails, running any scheduled updates etc. And the same backend means no changes to backup, compacting, fixup routines.

XPages has actually allowed developers to split UI and data since its inception. The limiting factor has been developer’s comfort with that approach, so data and UI have tended to be in the same NSF. Bluemix forces XPages developers to make that separation, but there’s no reason for not doing it in on premises XPages development. But interacting with that data outside of XPages will require some differences. From client-side frameworks, REST will be the usual method. DAS has allowed REST access to Domino data, though my personal view is that it’s not suitable for write access because it expects the person passing the data to DAS to validate it, and that could be more than just your application. There are plenty of blog posts about using JAX-RS to provide a more robust interface and I would recommend that for client-side frameworks. For Java-based frameworks, the XPages constructs like dominoView and dominoDocument actually teach us how to create the same kinds of wrappers that would be needed. Here, as in many other areas of development, XPages has reduced the hacks required to make it easier for developers to step beyond XPages for the front-end.

But there are still limited examples of taking an XPages application and “porting” it to a standard web application. That’s the focus of this series. To take a basic XPages application, as would have been developed by someone just starting in XPages; separate data and design and integrate more advanced approaches like MVC; then develop it as an OSGi application, still all running on Domino, but with a non-XPages front end; and finally surface the application outside Domino completely, but still with a Domino back end.

It may not be appropriate for all people and some may prefer an all or nothing approach to Domino. But I can see benefits both of standard web development and of the Domino server, whether in a traditional format or using the graph database implementation in OpenNTF Domino API. Moreover, my experience has only been with Domino, so I’m not comfortable with other database back-ends. My approach to learning and teaching XPages has always been to minimise complexity and minimise what’s new (so I have never advocated learning Java with your first XPages application). So personally, I prefer leaving the data where it is and be free to concentrate on getting familiar with a front-end framework.