As I have often said, one of the things I like about XPages is that you can always learn more and enhance your skills. The learning curve is steep at times, but there are aspects you can add on at a later stage. One of those is VariableResolvers.
Like so many Java constructs, the terminology is alien to traditional Domino developers – and I place myself in that category too. So what does it mean? Basically, you pass in a variable name as a String and the VariableResolver returns some kind of result – a String, a Boolean, an object of some kind etc. if you’ve developed anything in XPages and written any SSJS, then you’re already very familiar with the result. Whenever you write database.getView() or sessionAsSigner.getDatabase() or session.getEffectiveUserName() you’re using a VariableResolver. So whenever you use database, the VariableResolver takes that variable name and tries to match against all the variable names defined. When it finds “database”, it runs the Java code associated and returns the current Notes Database. The same is true for session, sessionAsSigner and everything else under the Global Objects category in the reference libraries.
As with many other things in the XPages world, VariableResolvers are extensible. And this is where the great power comes. You can create your own VariableResolver in a database, define your own variables and return whatever you want. The process is not complex, particularly if you’ve started working with managed beans. As with managed beans, it comprises a Java class for the functionality and an addition to the faces-config.xml for the implementation. The code can be found on XSnippets.
The first piece of code is the Java class for the implementation. The method of note is resolveVariable. This takes the name of the variable you want to resolve as a String. Here I use a very basic example “showRow” which returns true. But if we were able to look at the code of the VariableResolver within XPages, the variable “database” would run Java code to return the current Notes database.
The second piece of code is a simple piece of XML in the faces-config to tell it where to find the VariableResolver for the database.
But why use a VariableResolver? After all, the contents are scoped to application level. So why not just use a function called onPageLoad to set applicationScope variables (if they have not already been initialised) and refer to those? After all, that’s how we have coded our applications since we started working with XPages, and it works.
The answer is performance.
But unlike an applicationScope function, the variables are lazy-loaded. They are only resolved as and when they are used. So the initial load time of your application is enhanced. VariableResolvers will typically not run extremely lengthy code, so the call time for each method will not be intensive. And with basic caching (e.g. check if the object you’re returning has already been created before you call the method to create it), the number of lines of code run on each occasion should not be any different to calling applicationScope. There is no automatic caching of the results. So if your VariableResolver just calls a Java method each time, you will call that Java method every time. Caching has to be coded in, as with an SSJS function to initialise variables in applicationScope.
The performance of the VariableResolver is significantly better than Server-Side JavaScript in a Script Library and the performance is also better than using either Expression Language or Server-Side JavaScript to call a Java method, as I’ve shown in some Lotus User Groups this year. A snapshot of the results is shown below, where the rendered property of each row of a repeat is calculated in different ways.
A database can also have multiple VariableResolvers. Any VariableResolver in the faces-config will get called. This means you should also be able to create a VariableResolver as a plugin and make it available to the whole server. So, for a number of reasons, VariableResolvers are a topic well worth investigating.
Hi Paul – I bet naming convention is pretty critical here as well as supporting documentation if your aiming for a reusable resolver, the idea I assume is some form of black box functionality.
Yes, naming convention will be important. I’m not sure what would happen if you use a variable that is already defined by a developer in one of their databases. I haven’t tested that.
The main use case I was thinking of was for server-wide access to e.g. names.nsf, a log database, config databases for a database suite etc.