Subscribe via Feed

XPage Cheat Sheet #1 - The Page Lifecycle (Update)

Peter Presnell, Nov 6, 2009 3:39:17 AM

A few weeks ago I wrote a blog outlining the XPage lifecycle.  It appears that with 8.5.1 there have been a few changes made.  The following is an updated account of the lifecycle.

This example is based upon a single XPage (X) with 2 custom controls (A & B). Controls seem to be processed in the order they are listed.

The following are executed ONCE only:-
X.beforePageLoad
A.beforePageLoad
A.afterPageLoad
B.beforePageLoad
B.afterpageLoad
X.afterPageLoad

The next set of events are ONLY executed when a Full or Partial refresh occurs:-
X.afterRestoreView
A.afterRestoreView
B.afterRestoreView
If any control events have been fired they are executed following the afterRestoreView events.

The following now occur every time following the PageLoad or restoreView events
X.beforeRenderResponse
A.beforeRenderResponse (only occured with PageLoad in 8.5.0)
B.beforeRenderResponse (only occured with PageLoad in 8.5.0)
X.afterRenderResponse
A.afterRenderResponse (only occured with PageLoad in 8.5.0)
B.afterRenderResponse (only occured with PageLoad in 8.5.0)

The key difference for 8.5.1 being that the beforeRenderResponse and afterRenderResponse are now executed for the XPage and ALL custom controls regardless of whether a partial refresh or full refresh occurs.
Note: This is only a partial listing as the Document events are not (yet) included.

The same observations are still relevant:-
  1. PageLoad events are a good place to place code you only wish to execute the very first time the page is created.
  2. afterRestoreView events seem to be the best place for code that you wish to execute each time a refresh occurs.
  3. Events on a page/control will execute after the afterRestoreView events have fired so they will have access to any variables/object you create in these events.
  4. To have code execute every time the page is processed you need to place it in a PageLoad and an afterRestoreView event
  5. Wen placing code in a control's afterPageLoad event don't assume the beforePageLoad events of the other controls have fired or that the page's afterPageLoad has fired.
You can test this out on-line using a demo XPage I have created as part of a new XPages Kindergarten section of the .Domino Framework: http://www.dominoframework.com/DominoFramework.nsf/XPK_Events.xsp



1 responses to XPage Cheat Sheet #1 - The Page Lifecycle (Update)

Lance Spellman, January 7, 2010 9:05 PM

This is exactly what I was looking for, but my results don't jibe with what you've written. In particular, I'm NOT seeing the afterRestoreView events firing at all on my code. However, that's not what I really wanted to write about. The url for the post errors on clicking any button, just wanted you to know.
- Lance