ViewScope, Full Refresh and reloadPage()

Recently I picked up on a discussion about managed beans, viewScope and full page refreshes. If I understood the comments correctly, the expectation was that a full page refresh would reload the managed bean.

My IBM Connect session at the beginning of this year (which is being re-run for TLCC’s webinar next week) was all about expectations and troubleshooting to verify that the expectations are correct. So I had a database already set up with everything to verify and explain what actually happens.

From my use of Jesse Gallagher’s frostillic.us framework, I became aware that viewScope is set up when the component tree is first loaded, before the beforePageLoad event which occurs when the XPage first loads. A viewScoped managed bean will get initialised then.

A normal partial refresh then runs through the six phases – Restore View (when the component tree is restored from memory or disk), Apply Request Values, Process Validations, Update Model Values, Invoke Application and Render Response. The same component tree – and same viewScope – is re-used. A full refresh also goes through the same six phases, and also re-uses the same component tree. So all viewScoped datasources – dominoDocuments, managed beans etc. – still remain the same, regardless of whether a partial refresh or full refresh takes place. The scope of the refresh (partial or full) only affects what gets pushed from the server to the browser, it doesn’t affect the server processing or component tree and viewScope lifecycle.

To end the lifecycle for the current component tree and viewScope and reload a new version, the code needs to call context.reloadPage(). The lifecycle that runs then is particularly telling.

The standard six XPages lifecycle phases appear to run. But notice what happens during phase 5, Invoke Application. The component tree is re-initialised, beforePageLoad and afterPageLoad run, then Invoke Application completed and Render Response occurs. context.reloadPage doesn’t change what happens on the browser, it changes what happens on the server. It tell the server processing to reload the component tree and viewScope.

I don’t expect that the HTML area passed to the browser differs between a full page refresh and a full page refresh with context.reloadPage(). The key is that refresh (like the rendered property) affects the browser, reload (like the loaded property) affects the component tree lifecycle.

EDIT

Marcelo actually posed an excellent question, probably more excellent than he anticipated, certainly more interesting than I expected. What happens with context.redirectToPrevious()? As I expected, this runs in the Invoke Application phase. But below I’ve highlighted what happens next (the first box).

The current page’s Render Response phase is skipped. Instead, it runs Restore View and Render Response of the previous page (notice the different XPage name). It doesn’t create a new instance of the previous page, instead it goes to the pre-existing instance of the previous page. So that would have the same component tree and viewScope that existed last time the page was processed.

The second box is what happens when I just open the Welcome page. Notice when clicking on the page, the component tree (and so viewScope) are loaded and the beforePageLoad event runs, not Restore View.

Using context.redirectToPage(), though, runs that code in the Invoke Application phase of the first page, again skips Render Response, but acts like just opening the page – it creates the component tree, triggers the beforePageLoad event, and runs Render Response.