A few months ago Tim Tripcony blogged about a component’s binding property which was followed up with a NotesIn9 episode. On Tim’s blog, Jesse Gallagher asked if it had led to any cool app-structuring breakthroughs.
While preparing some XPages training materials, I realised there was one cool use of a component’s binding property that is very powerful. And it’s actually been around for quite some time without us really realising it.
With the Extension Library, there is the Pager Save State control. It’s something that was feasible before the Extension Library, but only through quite a few hacks. Anyone who has implemented it has probably just followed the steps in the XPages Extension Library book without fully understanding what’s being done. I can’t blame them: I wrote that part of the book and didn’t fully understand what was being done!
For those who are not aware, implementing the Pager Save State control comprises three steps. Two are pretty self-explanatory. Putting the Pager Save State control and binding it to the relevant view container on the XPage is obvious. When exiting a document, calling #{javascript:viewStateBean.restoreState()} is also pretty easy to understand. The code is restoring the state of the view using a method in a sessionScoped bean.
But there’s a third step has historically been one I didn’t fully understand. Until now.
On the relevant view container (e.g. a Data View), you have to set binding=”#{viewStateBean.dataIterator}”. If you remember Tim’s video or article, light bulbs are probably flashing now.
Yes, we’re binding the view container to the dataIterator property of the viewStateBean. The saveState() method uses the binding to get an easy handle on the dataIterator to save the current state – current number of rows, current first property, expanded paths, sort column, resort state. For anyone wanting to dive into code, the key class is BasicState class in com.ibm.xsp.extlib.component.data.FacesDataIteratorStateManager. That basically captures a HashMap of all the details about the current view container, which can then be applied when the view is restored.
This also fits in with the recent article I did on understanding views and the various levels of granularity in XPages.
I think you would agree that’s a cool use of the binding property, which has been under our noses for nearly three years! It also shows what can be done with bindings, allowing the state of a specific component to be written to a sessionScope variable and restored at a later date.
Cool…!
Binding is very interesting. I have used it a lot since Tim first told about it in his video. The way I use validators has been “re-invented” after I learned that 😉
I thought I had cracked the pagerSaveState until I created two nsfs, one holding the data and the other just the presentation.
In my presentation DB, I defined the data resource, a view and hey presto, I get the data presented. But then, when I add a pagerSaveState control, it doesn’t work. I think that somewhere along the way the original dataview is lost once I put the pagerSaveState control on the page. Any clues on how to solve this?
I’ve done a few apps with pagerSaveState where the data is in a separate NSF. So it’s not a technical limitation. I’d check logs for any errors and, if there’s nothing useful there, ask the question on StackOverflow including the source code for your dataView and pagerSaveState.