One of the powerful flexibilities of XPages is that virtually any property can be computed. That’s how it’s taught. But that’s not an apt explanation. A more precise explanation is that virtually any property can be used to run any server-side code, providing it also returns the relevant value.
This is an aspect I’ve taken advantage of in the past and did again just today. The first example is a dominoDocument’s documentId property.
There is a caveat to remember here, namely that if ignoreRequestParams is not set to “true”, the documentId property is retrieved from the URL. If found that is used and any code in the documentId – including any server-side code – is ignored. So the code will not be executed.
But if ignoreRequestParams=”true” then the documentId may be set in a scoped variable, for example. This was a process I was using in an application. If they had accessed the page before, I could just retrieve the relevant back-end document. But on the first time a specific user accessed the page, the document did not exist, so I wanted to create a new document and have it available in read mode. But I also wanted to initialise various fields.
In a traditional Notes Client app, that would have been done by creating fields that had a default value and setting the Form to inherit from the previously selected document. In XPages, novice developers may take a similar approach, adding hiddenInput controls and setting the default value. It’s a perfectly acceptable approach and one I’ve used myself.
But there is another way. I added code in the documentId to retrieve the relevant document and, if it did not exist, create it and initialise the various fields. The scoped variable was still set and returned by the documentId. This scenario was fine for me because I wanted the document to exist regardless of subsequent work.
The second situation was the default value for a Dojo List Text Box that was bound to a scoped variable. I wanted to use the first option from the list (the source of the list varied for different users). But elsewhere in the page the scoped variable was used to retrieve relevant language-specific fields. It was also used by a Java method to initialise a Collection of related documents. Setting the defaultValue property still means the scoped variable that component is bound to is still null until a partial refresh is triggered that updates those components. An alternative would have been to set the scoped variable in the beforePageLoad event, and that works fine. But the code to set it is disconnected from the component that uses it, which can slow down diagnosing the component’s behaviour for support. (As I found out, because the defaultValue property I was trying to set was getting overridden by the beforePageLoad code setting the scoped variable!)
But beforePageLoad would not work in this scenario, because the Java object for which I was initialising a Collection was scoped to a panel, so could not be referenced at the XPage level. So I put the code to retrieve the default value, pass it to my Java method, set the scoped variable and retrieve the value all in the defaultValue property.
However the defaultValue property was computed, whether inline, via a bean or via a Controller class, additional code tangential to the purpose of setting that property can still be run. It can make code more readable and easier to debug, as well as minimising challenges caused by conflicting functionality from various areas of the XPage. It just requires a little thinking outside the box, a good habit to get into if you’re looking to push boundaries in XPages.
