The JSF life cycle

The Facescontext contains status information for all requests that are processed by a single JavaServer Faces request and related to the rendering of the corresponding response. It is passed to each stage of the request processing life cycle and may be modified.

Note Event listeners can affect the JSF life cycle in one of the following three ways:

(1) Let the life cycle proceed normally.

(2) Call the Renderresponse method of the Facescontext class to skip the rest of the life cycle and jump directly to the render response stage.

(3) Call the Responsecomplete method of the Facescontext class to completely skip the other phases of the life cycle.

The specific information for the two methods is as follows:

Abstract public void Renderresponse ()

Notifies the JavaServer faces implementation that after completing the current phase of the request processing life cycle, you should immediately enter the rendering response phase, ignoring any stages that have not yet been executed.

Throws IllegalStateException: This method is called when this instance is disposed

Abstract public void Responsecomplete ()

Notifies the JavaServer Faces implementation that an HTTP response has been generated for this request (such as HTTP redirection) and that the request processing life cycle should be terminated immediately after the current phase is complete.

Throws IllegalStateException: This method is called when this instance is disposed

Request (typically not in the JSF lifecycle)

First stage: Restore view

Second Stage: Application Request value + process Event

Phase III: Process validation + process events

Phase IV: Update model values + process events

Fifth stage: Invoke Application + Procedure event

Sixth stage: Rendering response

Response (typically not in the JSF life cycle)

The end-to-end request, the response, is separate from the outside. And the rest is the real process of JSF lifecycle processing.

First stage: Restore View

In the first phase of the JSF life cycle, restore view, there is a request from the Facesservlet controller. The controller examines the request and extracts the ID of the view, which is determined by the name of the page.

The JSF framework controller uses this view ID to find the component for the current view.

If the view does not already exist, then the JSF controller creates it.

If this view already exists, then the JSF controller will use it. This view contains all the GUI components.

(digression: This also causes the AJAX request to be unable to reset the value of the input box on the page during the life cycle, causing the validation error to open dialog again, and the error value still exists.) But the benefits outweigh the disadvantages and only need to modify the JSF life cycle in the JSF lifecycle, After Ajax verification, enter the life cycle again and reset the content! Resetinputajaxactionlistener. Just OK).

This phase of the life cycle is represented as three view instances: New View, original view, and back view, each view being handled differently.

The Facescontext object contains all the state information that JSF needs to manage the state of the GUI component of the current request in the current session. Facescontext saves the view in its own Viewroot property, Viewroot All JSF components that contain the current view ID.

1. In the case of a new view, JSF builds a view of the faces page and binds the event handlers and validators to the component. This view is saved in the Facescontext object.

2. In the case of the original view (a page is loaded for the first time), JSF creates an empty view. This empty view is populated when user events are generated. JSF can transition directly from the original view to the stage of the response.

3. In the rear view (postback) in the case (the user returns a page that was previously visited), the view that contains the page already exists, so only a recovery is required. In this case, JSF uses the state information of the existing view to refactor the state. The next stage of the rear view is the application request value.

Second Stage: Application Request value + process event

The purpose of applying the request value phase is to have each component retrieve its current state information. It is closely related to the JSF converter.

These components must first be retrieved or created (using their values) through the Facescontext object. Although component values can also be retrieved from a cookie or header file, they are usually retrieved by request parameters.

If the Instant event processing property of an input component immediate= "True/false" is not set to true, the values are converted. Therefore, if the field is bound to an integer property, the value is converted to an integer type. If the conversion of the value fails, an error message is generated, queued in Facescontext, the message is displayed during the response stage, and all validation errors are displayed.

If the immediate event handling property of an input component immediate= "True/false" is set to true, then these values are converted to the appropriate type (note: It is converted to the appropriate type, that is, the decision to convert is NOT!!!), and validation is performed. The converted values are then saved to the component. If a value conversion or validation of a value fails, an error message is generated, queued in Facescontext, the message is displayed in the stage in which the response is generated, and all validation errors are displayed.

Phase III: Process validation + process events

The first event processing in the life cycle occurs after the application request value phase.

At this stage, each component has some values that need to be validated against the application's validation rules. These validation rules can be pre-defined (provided in JSF) or defined by the developer.

The values entered by the user are compared with these validation rules. If the value entered is not valid, an error message is added to the Facescontext and the component is represented as invalid.

If a component is represented as invalid, then JSF goes to the stage in which the response is generated, in which the current view is displayed, along with the validation error message.

If there is no validation error, then JSF goes to the stage of updating the model value.

If the prompt processing property in a command component immediate= "True/false" is set to true, then "will also only skip the validation process on this form".

Fourth stage: Updating model values + process events

This phase is responsible for updating the actual value of the server-side model.

Typically, this is done by updating the properties of the background bean. Only the bean properties that are bound to the component values are updated. (In fact, Backbean gets the attribute value ...)

Note that this phase occurs after validation, so you can ensure that the values copied to the bean properties are valid (at least at the form field level, and may still be invalid at the business rule level).

Fifth Stage: Invoke Application + Procedure event

At this stage of the lifecycle, the JSF program invokes the program to handle the form's commit operation. The component values have been typed and validated and applied to the model object (in fact, the backstage Backbean has got the value of the foreground, it is unclear why some of the information is always very advanced,-- !), so you can now use them to execute the application's business logic.

At this stage, you can also specify the following logical view for a given sequence or many possible sequences, which can be achieved by defining a specific result for a successful form submission and returning the result.

For example: When the output is successful, redirect the user to the next page. To make this navigation work, you need to create a mapping in the Faces-config.xml file to a "successful output" as a navigation rule.

Once the navigation has occurred, you are transitioning to the last phase of the life cycle.

Sixth stage: rendering response

Display all components in the current state in a view

The JSF life cycle