The life cycle of the JavaServer faces application begins when the client makes an HTTP request for the page and ends when the server rings the page and translates to HTML.
The JSF life cycle is typically divided into two phases:
#执行阶段
#渲染阶段
1. Implementation phase
The JavaServer faces application Lifecycle execution phase contains the following sub-stages:
Restore view: Restores or creates a server-side component tree (view) that represents client user interface information in memory.
App Request value: Update These server-side components with the latest data from the client.
Process validation: Performs validation and data type conversions on new data.
Update model values: Update server-side model objects with new data.
Invoke application: Invokes the application logic required to satisfy the request, and then navigates to the new page if necessary.
Render response: Renders the response to the requesting client.
JSF Request-Response life cycle steps:
1.1 Recovering the View stage
When a client requests a JavaServer faces page, the JavaServer faces implementation begins the recovery view phase. At this stage, JSF builds the components in the view as a view of the request page, linear event handlers, and validators, and saves the view in the Facescontext instance.
If the request to the page is a postback, then the view corresponding to the page already exists in the Facescontext instance. At this stage, JavaServer faces implements the restore view by using state information that is saved on the client or server.
1.2 Application Request Value Phase
During this phase, the component tree is restored during postback requests. A component tree is a collection of form elements. Each component in the tree extracts its new value from the request parameter by using its decode (Processdecodes ()) method. After that, the value is stored locally on each component.
If any decoding method or event listener calls the Renderresponse method on the current Facescontext instance, the JavaServer faces implementation skips the render response phase.
If any event is queued at this stage, the JavaServer faces implementation broadcasts the event to an interested listener.
You can call the Facescontext.responsecomplete () method if your application needs to redirect to another Web application resource or to generate a response that does not contain any javaserver faces components.
If the current request is recognized as a partial request, the partial context is retrieved from Facescontext and a partial processing method is applied.
1.3 Process Validation Phase
At this stage, JavaServer faces handles all validators registered on the component by using its validate () method. It examines the component properties of the specified validation rule and compares those rules with the local values stored for the component. JavaServer faces also completed the conversion of the input component without setting the immediate property to true.
The JavaServer faces implementation skips the render response phase if any of the validation methods or event listeners have renderresponse methods on the current facescontext.
You can call the Facescontext.responsecomplete method if your application needs to redirect to a different Web application resource or to generate a response that does not contain any javaserver faces components.
If events are queued at this stage, the JavaServer faces implementation broadcasts them to an interested listener.
If the current request is recognized as a partial request, the partial context is retrieved from Facescontext and a partial processing method is applied.
1.4 Updating the model value stage
After making sure that the data is valid, it traverses the component tree and sets the corresponding server-side object property to the component's local value. The JavaServer faces implements only the update of the input component's Value property to point to the Bean property. If the local data cannot be converted to the type specified by the bean attribute, the lifecycle advances directly to the render response stage to re-render the page and display an error.
If any Updatemodels method or any listener calls the Renderresponse () method on the current Facescontext instance, the JavaServer faces implementation skips the render response phase.
You can call the Facescontext.responsecomplete () method if your application needs to redirect to another Web application resource or to generate a response that does not contain any javaserver faces components.
If any events are queued at this stage, the JavaServer faces implementation broadcasts them to an interested listener.
If the current request is recognized as a partial request, the partial context is retrieved from Facescontext and a partial processing method is applied.
1.5 Invoking the application phase
At this stage, JSF handles application-level events, such as submitting a form or linking to another page.
Now, if your application needs to redirect to another Web application resource or generate a response that does not contain any JSF components, you can call the Facescontext.responsecomplete () method.
After that, the JavaServer faces implementation transfers control to the render response stage.
1.6 Rendering Response phase
This is the final phase of the JSF life cycle. At this stage, JSF builds the view and delegates the permissions to the appropriate resources to render the page.
If this is the initial request, the component represented on the page is added to the component tree.
If this is not the initial request, the component has been added to the tree and does not need to be added.
If the request is a response and an error is encountered during the process validation phase or the update model value phase during the application request value phase, the original page is rendered again at this stage.
If the page contains a h:message or h:messages label, any queued error messages are displayed on the page.
After the contents of the view are rendered, the state of the response is saved so that subsequent requests can access it. The restore view stage can use the saved state.
2. Rendering Phase
At this stage, the requested view acts as a response to the client browser. View rendering is the process of generating output in HTML or XHTML. So the user can see it in the browser.
Take the following steps during the rendering process.
The application is compiled when the client makes an initial request to the Index.xhtml Web page.
The application is executed after compilation, and a new component tree is built for the application and placed in the Facescontext.
Populates a component tree with a component represented by an El expression and its associated managed bean properties.
Based on the component tree. A new view is created.
The view is rendered as a response to the requesting client.
The component tree is automatically destroyed.
In subsequent requests, the component tree is rebuilt and the saved state is applied.
Study of the JavaServer Faces Lifecycle