Last week I did a session on modernising Domino and XPages applications. Filling an hour seemed daunting when the session was accepted. So I went to the Oxford English Dictionary definition of modernisation:
The process of adapting something to modern needs or habits
Using that as a starting point gave me a very broad canvas, even including a number of aspects to leave out of scope. Those included third party products for modernising Domino applications, modernising the developer’s toolset and modernising the developer’s skillset. Domino Designer was also out of scope.
I took four examples for modernisation, all covering getting data out of a Domino application and into Excel, all extending an existing application. The application I chose was the XPages Extension Library database, which is also the Node Demo database. The source code is on my GitHub repository.
Notes Client: Edit > Copy As Table
Modernisation can be just leveraging functionality added at a platform level. I was hopeful that some users are not aware of Edit > Copy as Table, and asked the question. I was glad to get the answer I wanted. And it’s a valid and easy way to export selected entries from a view into Excel. Modernisation isn’t just something we do, it’s something that’s done for us. And being aware of what’s added is critical to having a modern application.
XPages: Apache POI
For the second example I modernised the XPages interface, on the “Categorized View – 3 columns” tab of the Data View page. I set the Data View to show checkboxes and added an “Export to Excel” button to put the IDs of the select documents into sessionScope and redirect to the ContactsExport XPage. This XPage is just an XAgent that calls
extlib.ExcelUtils.exportSelectedContacts(). That points to code in a Java class, but it’s a bit more granular than many Excel exports.
There are three specific methods that are used by a couple of methods:
createExcel()– at line 39, creates the Excel spreadsheet, building the header row.
writeContacts()– at line 67, takes an HSSFSheet, a Notes document and a row on the spreadsheet to write the data to.
finaliseWorkbook()– at line 94, tidies up the spreadsheet.
exportSelectedContacts() method at line 107 that is called by the XAgent, creates the spreadsheet, writes rows for each document in sessionScope and sends the finalised spreadsheet to the server.
One could say that’s not the end of the XPages enhancement of the application. There is also another XAgent.But this one isn’t intended to be called from XPages, instead it’s being called from elsewhere (more of that later). It calls
extlib.ExcelUtils.emailSelectedContacts() which is also in that same Java class. This is slightly more complicated, starting at line 142. But this uses the same three methods that the
exportSelectedContacts() method uses. But it’s intended to be used from an HTTP POST request into the server. The application needs anonymous access for it to work, but the code calling it could pass credentials, or the code could be centralised in a separate application. But even though it’s anonymous access, it is secured. If the POST request doesn’t have a secretKey header parameter and it’s not what’s expected, a 403 error will be returned. This time, instead of using sessionScope – which won’t exist – it picks up the IDs from the JSON object posted in, an array in the data JSON element. It then emails the finalised spreadsheet to whatever is passed into the REST service.
Here we’re using an XAgent because it’s easier, avoids requiring Excel on the server, refactors existing XPages code for a different purpose. It also highlights why XPages developers who have restricted themselves to SSJS and avoided understanding standard packages like Apache POI – which are not particularly challenging, especially to anyone who’s interacted with Excel in LotusScript – have limited their opportunities.
In the next part we’ll cover off some more modernisation approaches, for other interfaces. And we’ll show that modernisation is a never-ending task: even the most modern interface can be modernised further.