You can run IQJam in your company on your Domino server. Learn how...
Username: Password:
Reset Password | Register
 
Home | Leader Board | Tags | Help
Back to view...
Is The Page Lifecycle Documented Anywhere? 
Does anyone know if any detailed documentation exists of the page lifecycle for an Xpage?  By that I mean from the time the page is created until the page is destroyed what events get fired and when along with milestones such as state and access to the HTML.  I am especially interested in the full and partial refreshes that can occur and what events they trigger.  Plus where validation fits in.... When I did .Net development all us developers had a flowchart of the .Net page lifecycle as it was a vital part of figuring out where to place code  that would run when needed and when it had access to all the data that was needed.  At the moment I am largely in the dark.
Domino Development / XPages
Tagged
Peter Presnell - 10 months ago |  |  | Viewed 134 times

There are 2 Answers

0votes
Here's a link on 'The Events "No data validation" option in XPages' that may go some way to answering your question...
"How "No data validation" works in the JSF Lifecycle
The explanation for all of this requires an understanding of the JSF(Java Server Faces) lifecycle.
When the user submits a page to the server, the submission is processed in different phases, where in each phase it goes through all the controls and processes them.
When you submit a page, on the server it first restores the server-side control tree (Restore View phase), then it goes through all controls and copies the values from the browser form into each control's "submittedValue" field (Apply Request Values phase). Then it validates each control in the Process Validations phase, adding an error message to a list if not valid. Also if the field is configured as a non-string type, like Date, it'll convert it to a Date object, adding an error message to the list if there's a conversion problem. If the control is valid and converts OK, then the conversion will delete the value from the "submittedValue" field, and put the converted value into the control's "localValue". Then the phase will save the converted value into the underlying document field and remove the control's "localValue". Next the Invoke Application phase will process any actions associated with the event that submitted the page. Finally, if the action did not move to a different page, then the control tree is output as a HTML page that's returned to the browser (Render Response phase).
There are other explanations and diagrams of the JSF lifecycle on the web if you want to look into it more. "


Paul Hannan - 10 months ago | 
Voting
Vote on the answer to show whether you think the answer is correct or useful to the rest of the community.

Answers with more votes are more visible to the rest of the community


1votes
Marked as correct on: 10/7/09 9:39 PM
From Peter Presnell - http://www.bleedyellow.com/blogs/dotdomino/entry/xpage_cheat_sheet_1_the_page_lifecycle5?lang=en

There seems to be a lot of essential documentation about XPages missing from the on-line documentation.  One of the key items I have been searching for is a description of the page lifecycle for an XPage.  After performing some experiments I have mapped out the following basic lifecycle.  I will try and expand on it as time and the need dictates....
:
The following example is based upon a single XPage (X) with 2 custom controls (A & B).
Note: (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 then executed here.....
:
The following occur next, although it is not yet clear if this exact pattern is always repeated for Full & Partial Refreshes.
X.beforeRenderResponse
A.beforeRenderResponse (only appears to occur with PageLoad)
B.beforeRenderResponse (only appears to occur with PageLoad)
X.afterRenderResponse
A.afterRenderResponse (only appears to occur with PageLoad)
B.afterRenderResponse (only appears to occur with PageLoad)
:
So what exactly does this mean?
  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 probably 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.


Paul Hannan - 10 months ago | 
Voting
Vote on the answer to show whether you think the answer is correct or useful to the rest of the community.

Answers with more votes are more visible to the rest of the community


 

Latest Answers for Domino Development / XPages