JSF Lifecycle
From Shrubbery
- The JSF Lifecycle and Seam
Contents |
[edit] Ordinary JSF Lifecycle
[edit] RESTORE_VIEW
Restore the state of all the JSF components in the view, or create a new tree of view objects if it doesn't exist.
- After JSF restores or creates the view, Seam will restore the conversation and apply the page parameters.
- For GET requests, this phase will always create a new view and go on to RENDER_RESPONSE
- For JSF postback requests, this phase will restore the view and go on to APPLY_REQUEST_VALUES
[edit] APPLY_REQUEST_VALUES
Values are set into the JSF components objects in the view (not Seam components, JSF components).
- If here are values that cannot be converted or the view object has something wrong with it then this phase can sometimes fail silently and go directly to RENDER_RESPONSE.
- The 'model' (Seam components referenced by EL) will not be updated at this time.
[edit] PROCESS_VALIDATIONS
Validate the values. If the validations fail, JSF will skip to RENDER_RESPONSE.
[edit] UPDATE_MODEL_VALUES
Copy the values into the backing beans. Sometimes this fails due to type conversion errors, or improperly declared properties on the backing beans (Seam components). In this case, JSF may decide to fail silently and go directly to RENDER_RESPONSE without setting any further values in the model.
[edit] INVOKE_APPLICATION
Invoke the application method, get an 'outcome' string.
[edit] RENDER_RESPONSE
Before rendering the response Seam will process selections, invoke page actions, and store the conversation.
Determine the next view from the outcome. Render it.
[edit] Seam JSF Lifecycle
[edit] After RESTORE_VIEW
Seam does two things after restoring the view:
- Restore the conversation context.
- Apply page parameters - Convert and set the values in the Seam component backing beans.
[edit] Before RENDER_RESPONSE
Seam does three things before rendering the response:
- Process data model selections
- Invoke page actions - Page actions are invoked after the page parameters are applied. If the request is a JSF postback, the page actions are invoked after the INVOKE_APPLICATION phase as well. This means a backing bean that is bound to a JSF button and a page action might get two method invocations before rendering. Actually a few things happen here:
- Conversation required - If a conversation is required and there isn't one, redirect.
- Login required - If a login is required and there isn't one, redirect.
- Restriction expressions - Restriction expressions may or may not throw exceptions that cause a redirect.
- Actions are processed in order.
- Store the conversation for later.
[edit] See Also
Categories: JSF | Seam



