The beta of XPages in Bluemix introduces the concept of splitting design from data, with (on the whole) one NSF for the XPages components and one for the data. But for me that’s not a new concept, and has not been for some time.
Accessing a separate database is nothing new in XPages. It was something I was doing in 8.5.0 and something I first did programmatically in the first release of XPages OpenLog Logger.
Consequently, pointing all data to a separate data database is similarly straightforward and something I’m doing for an upcoming set of demo applications. The core code I’ve added onto XSnippets.
It requires some Java utility methods, the first and most complex of which are for retrieving a notes.ini / xsp.property variable. I’ve ported these as-is from XPages OpenLog Logger, but in most scenarios I suspect the xsp.property would be a better approach than notes.ini. Then follow the getter and setter. As you can see from the code on XSnippets, this lazy-loads the variable into the class, something that becomes a standard approach once you move into Java and have easy access to e.g. a bean for the page. Finally, there’s a helper method that uses the variable to get the relevant Domino database, for everywhere you want to use from Java.
On the surface, converting an existing application may seem hugely onerous, but it’s not. A find-and-replace on
ExtLibUtil.getCurrentDatabase() to repoint to
AppUtils.getDataDb() handles all Java references. And for any datasources, you just need to add in the
databaseName property, like this:
AppUtils.getDataDb(), with the same
importPackagestatement. Alternatively, you could use an applicationScoped bean that only stores the path (scoped variables can be accessed via just the variable name, although it’s up to the developer to ensure the same variable name is not also used in request, view or session scope). Personally, where all my business logic is now in Java, calling a utility method is easier and cleaner.