3. JSF Runtime Architecture

JSF code runs in a Web Tier container in the same way as servlet code. JSP files are the standard view technology used for JSF components running on the Web; we usually code JSF inside a JSP file.

• The browser issues an HTTP request to the web server.
• The web server finds the URL’s virtual directory name in the web.xml file and passes the request to the Faces Servlet that is running (or that will be started) on the web server.
• The Faces Servlet handles the request by passing control to an object created using the life cycle class (javax.faces.lifecycle.Lifecycle). This Lifecycle class processes the JSF file using a set of steps called the JSF Life Cycle.
• The servlet accesses any necessary Model layer code to obtain values from the data source. The servlet instantiates the bean if a component property value refers to an element in a backing bean.
• The Faces Servlet then assembles the page (shown here with a .jsp). The file runs through the normal JSP translate and compile steps.
• The application then assembles an HTTP response using a render kit which converts the display elements to an HTML page. It then sends the response to the web browser. The process for other display types, such as for a PDA or cell phone client, is similar, although their render kits are different.

JSF Life Cycle

==================

The FacesServlet and Lifecycle objects work together to process the HTTP request and assemble an HTTP response using the six steps. A JSF application can support requests to non-JSF components, but processing of a non-JSF request follows an abbreviated version of the life cycle.

1. Restore the Component Tree

The components used in a JSF application are arranged in the file in a hierarchical way. This hierarchy, the component tree (UI tree), corresponds to the tag hierarchy we see in an HTML file (plus any other files or components included on the page at runtime).

2. Apply Request Values

In this step, the Lifecycle instance populates the components in the component tree with data from the request parameters. These values are held in a buffer area and the process does not validate the assigned datatypes yet. Events that apply to this step are also processed.

3. Process Validations

This step applies conversions (defined in converter components) that translate the plain-string value loaded into the buffer for each component in the preceding step to the datatype assigned to that component. We can define validation (using validator components) — for a component to check the value assigned to it. Validations and conversions are bypassed for a particular component if that component is assigned an immediate property value of “true”. If any validation or conversion fails, the error messages are queued and the process jumps to step 6.

4. Update Model Values

Just as step 2 sets values for the components in the component tree from the request, this step sets the values for the corresponding components in the Model layer code. As before, if errors occur in validations or conversions, the messages are queued and the process jumps to step 6 for rendering the response.

5. Invoke Application

This step performs application-level tasks, such as page navigation, as appropriate to the request. Events are handled if the page being restored contains components that fired events. Therefore, this step runs any event code we have written.

6. Render Response

If this is the first request to a page, control is passed from step 1. The FacesServlet object builds the component tree as specified in the JSF file and stores the tree in the FacesContext object. The framework then requests components in the tree to be rendered; this results in the components using appropriate render kit to output markup text, which the JSF servlet buffers into the final page definition. Messages that were queued from previous steps are written to the output as well. In addition, the state of the page is stored so that subsequent requests can use it for the restore view step. This step ends with the Faces Servlet sending an HTTP response to the browser containing the buffered page output.

JSF-Oriented Files
==================
When we set up a project for JSF work in JDeveloper by including the JSF technology scope in the project, the web deployment descriptor file (web.xml) is automatically modified so that it contains a definition that the Faces Servlet will load when the application starts as shown here:

 
  Faces Servlet
  javax.faces.webapp.FacesServlet
  1
 

Additional code in web.xml sets up a pointer for requests that contain a designated virtual directory (such as “/faces/”).

Managed Beans

A managed bean (MBean) is a Java object containing code used to handle operations and data for a resource (in this case, for components on the page). In JSF work, a managed bean is manipulated (created and destroyed) by the JSF controller. A managed bean may be associated with the JSF JSP page file. For example, a login.jsp page file would use a managed bean class file typically named “Login.java.” The Java file contains the code needed to process events that are outside of the declarative framework. In addition, the managed bean class can contain accessors (getters and setters) for the objects on the page (for example, text fields), so we can manipulate the values of these objects programmatically.

Events and Action Listeners: One of the strengths of the JSF framework is its rich model for event handling. Events occur due to some user interaction, such as a button click or list selection. We can write action listener methods in the managed bean to handle these events. For example, an OK button called “okButton” in a JSF page could have a corresponding action listener method called okButton_action() written in the managed bean.

faces-config.xml

This XML file, called the application configuration resource file, contains definitions that specify the following:

• Navigation rules for defining flow from one page to another.
• Managed bean definitions for making JavaBean code accessible in the application.
• Render kits that are used to display the page in a certain encoding, such as HTML or WML.
• Converters, mentioned before, which change the type of data from the plain-vanilla string supplied by the HTTP request parameter value to a specific datatype for a component value.
• Validators, which check the value of data (for example, the range of the value or its length).

JSF JSP file

The JSF JSP file (or the JSF file) contains all user interface components arranged in the same kind of hierarchy as with any HTML or JSP file. When developing a JSF application, we write View layer code in the JSF JSP file, and  Model and Controller code in the managed bean and faces-config.xml file. We can create and run JSF JSP files in two different forms: a JSP page and a JSP document.

JSP Page and JSP Document: The JSP page is a file with a .jsp extension that contains both HTML tags and JSP-oriented tags. It is the traditional style used for JSP files. The benefit of this file type is that it allows to use HTML tags, which we can display and design in an HTML editor such as Dreamweaver. The JSP document is a file with .jspx extension that contains only well-formed XML code.