A Possible Role For XPages

Home » A Possible Role For XPages

A comment from Mark Maden on my recent blog "Thoughts on the Problem of XPages" prompted me about a potential area XPages could add value for the future. One of the strengths of XPages from the start has been flexible reporting. Indeed my very first session at a conference, at BLUG (now Engage) nearly ten years ago demoed a dashboard-style report using XPages Repeat Controls with three different datasources - an @DbColumn, a dominoView and a programmatic collection. The report allowed drill-down into holiday and person records. You can see it at http://paulswithers.me.uk/ug/viewpoint.nsf (choose 2017 or 2018 for the year). It was a completely innovative style of navigation and a type of dynamic report that couldn't be done on the Notes Client and still can't, outside of XPiNC.

For exporting, XPages handled those requirements with Apache POI, albeit a solution that really required using Java. POI4XPages offered some options with a lower skill-set, although I've never really investigated that fully - I already had good Java skills. iTextPDF could also be used for PDF generation.

Fast forward ten years and many of the third-party reporting solutions for Notes Client have long left the platform, leaving a void. The resurgence of the Notes Client with Domino Mobile Apps is great, but this kind of reporting is still left as a gap. At Engage this year I used a Node-RED server to generate and post a spreadsheet from JSON, but there were some limitations. Even with the rich client, exporting to spreadsheets means outputting a CSV and importing or depending on platform-specific APIs. There's the same limitation for documents. With a lightweight client, browser-based, that's going to be even more challenging.

And then there's HCL Leap, the low code offering. It does forms and views well (the previous name for the product was Forms Experience Builder). Workflow is an area already in hand, but reporting will be an obvious other requirement. There is REST API access, but nothing in-built.

But reporting is an area XPages excels. The combination of XPages with something else was something I had already identified as a potential when HCL Places was first announced. Authentication has always been the main barrier for this, but with consolidation of Notes ID password and internet password in V11, that may offer some way of providing seamless authentication between the lightweight client, an HCL Leap front-end and an XPages front-end. It would certainly allow direct access to Domino data.

Even for reporting, XPages is not low code, something that would need to be addressed. But that's not insurmountable. POI4XPages also shows lower code exporting is possible.

Let me be straight, I'm not saying "XPages fills this gap, we must use it." It fills the gap. I'm sure it's not the only solution that fills the gap. It may not be the best. It may require too much work to make it "low code enough". It may be too bulky. A more basic web component framework receiving JSON may be a better option, even if more effort is required on creating a builder for low code users or power users. But XPages is definitely an option, and it may be a reason for a resurgence of part or all of XPages. It may mean it gets used without the deep modernisation some are asking for. And it might not get used at all. Who knows?

But while some are laying XPages in its grave, again, it's worth highlighting something significant. LotusScript was declare dead some years ago, probably by the same people. For anything to have a future, it's a case of looking for how it could be used, where it could add value, how it could evolve. Evolution is after all the key to survival.

Leave a Comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Scroll to Top