JSF Lifecycle

From Shrubbery

Jump to: navigation, search


The JSF Lifecycle and Seam

Contents

[edit] Ordinary JSF Lifecycle

The 'vanilla' JSF lifecycle
The 'vanilla' 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.

[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

JSF Lifecycle with Seam Phase Listener
JSF Lifecycle with Seam Phase Listener

[edit] After RESTORE_VIEW

Seam does two things after restoring the view:

  1. Restore the conversation context.
  2. 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:

  1. Process data model selections
  2. 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:
    1. Conversation required - If a conversation is required and there isn't one, redirect.
    2. Login required - If a login is required and there isn't one, redirect.
    3. Restriction expressions - Restriction expressions may or may not throw exceptions that cause a redirect.
    4. Actions are processed in order.
  3. Store the conversation for later.


[edit] See Also

Personal tools