Musings on ignoreRequestParams
We’ve all made the mistake: we have multiple dominoDocument datasources on a page and we forget to set
ignoreRequestParams="true" on one of them and chaos ensues. At which point we start cursing ourselves and the need to do it. It’s a topic I covered in my session at IBM Connect and also at Engage this week. But default properties need to be set and what are the alternatives? Let’s discuss them and I think you’ll agree we may have the best (and, if you disagree, when the components are open sourced you can extend it for yourself!)
Current Default Behaviour –
The default behaviour works well for new XPages developers: the view components (View Panel, Data View etc.) add a link to a column which opens the document passing the documentId to the resulting XPage. That is standard of other web frameworks, particularly REST-based ones, which pass the entry’s unique reference in the URL to the underlying REST service. More experienced XPages developers may create the link themselves and could choose to hide the UNID by storing it in e.g. sessionScope. That would avoid the need to use the URL as a source to load the document. But XPages beginners would always need to define the relevant sessionScope variables, plus make sure they did not accidentally override them!
Opposite Behaviour –
The obvious alternative would be to ignore the URL as a source by default. Having multiple dominoDocument datasources on a single XPage is something that takes time to do if you’ve come from Notes Client development, because it needs a major shift in thinking. But every time a document is edited, a dominoDocument datasource will be added. So for beginner XPage developers, it would be more frustrating to always have to set
ignoreRequestParams to false on that first datasource.
Default Based on First Datasource
What might seem a plausible option is to identify the first dominoDocument datasource on the XPage and use the URL as the source for that by default. But what if that datasource has
ignoreRequestParams="true"? Should the next dominoDocument datasource us the URL or no datasource? Probably the latter would be best.
But then consider the scenario where that datasource is on a Custom Control. As I showed in my session, although a Custom Control is a separate design element, when the XPage is rendered that Custom Control’s content is just “pasted” into the parent XPage (which is why objects don’t need passing to Custom Controls, you can just reference the variable). so depending on where the Custom Control was placed, a dominoDocument datasource on it could behave differently. That would be very confusing, particularly because nothing else on an XPage behaves like that. Furthermore, “expected” behaviour could change if another Custom Control or additional datasource was added subsequently in development or in a later development phase. That would be very confusing!
And then there’s the Dynamic Content Control. The first datasource would depend on which facet was being loaded by default, because the current facet is the only area in the XPage’s component tree initially. So you might get different outcomes depending on specific scenarios.
Similar to the Dynamic Content Control is the Switch Control, but with that every facet is loaded to the component tree initially – it’s more like a standard XPage design.
Then there is also the Mobile Single Application Page control. Picking up URL parameters for only the first dominoDocument datasource on the Single Application Page would get confusing.
And there’s also the
requestParamPrefix functionality, which allows multiple datasources to all pull from the URL parameters.
What seemed an initial possibility really just wouldn’t work in reality. So based on these deeper musings, I think the way it works is actually the best and easiest to understand functionality. Even though we have all got caught out by the inherent gotcha and cursed it on mor than one occasion!