Table Of Contents
1. Introduction. 3
2. Files In JSF Application. 3
3. Directory Structure. 4
4. XML files. 4
5. JAR files. 4
6. How does JSF work?. 5
7. JSF Lifecycle. 7
8. A simple JSF Application. 10
9. A simple JSF Portlet Application. 10
10. References 11
INTRODUCTION
JavaServer Faces (JSF) is a technology that helps you build user interfaces for dynamic Web applications that run on the server. The JavaServer Faces
framework manages UI states across server requests and offers a simple model for the development of server-side events that are activated by the client. JSF is
consistent and easy to use.
A JSF application looks like any other servlet/JSP application. It has a deployment descriptor, JSP pages, custom tag libraries, static resources, and so on. The user interface of a JSF application is one or many JSP pages that host JSF components such as forms, input boxes, and buttons. These components are represented by JSF custom tags and can hold data. A component can be nested inside another component, and it is possible to draw a tree of components. In fact, a JSP page in a JSF application is represented by a component tree. Just as in normal servlet/JSP applications, you use JavaBeans to store the data the user entered.
Files in a JSF Application
(1) JSP pages
(2) Java class filesPublish Post
(3) XML files
(4) JAR files
(5) Resource bundle (if any)
The important xml files are:
- web.xml
- faces-config.xml
The jar files required are: (specific to JSF applications)
- commons-beanutils.jar
- commons-collections.jar
- commons-digester.jar
- commons-logging.jar
- jsf-api.jar
- jsf-impl.jar
- jstl.jar
- standard.jar
Directory Structure:
Project
/ JavaSource
Properties file (Resource Bundle)
.java files
/ WebContent
/ WEB-INF
/ classes
/ lib
JAR files
faces-config.xml
web.xml
/ pages
XML files:
web.xml
This file inside the WEB-INF folder is the Web Application Deployment Descriptor for your application. This is an XML file describing the servlets and other components that make up the application.
faces-config.xml
This file inside the WEB-INF folder is the Java Server Faces configuration file. This file lists bean resources and navigation rules.
JAR files:
commons-beanutils.jar: Utilities for defining and accessing JavaBeans component propertiescommons-collections.jar: Extensions of the J2SE Collections Frameworkcommons-digester.jar: For processing XML documentscommons-logging.jar: A general purpose, flexible logging facility to allow developers to instrument their code with logging statementsjsf-api.jar: Contains the javax.faces.* API classesjsf-impl.jar: Contains the implementation classes of the JSF Reference Implementation
Note that the JSF framework uses the Java Server Pages Standard Tag Library (JSTL), and therefore it is assumed that the web container you use provides the necessary JAR files for JSTL.
How Does JSF Work?
A JSF application works by processing events triggered by the JSF components on the pages. These events are caused by user actions. For example, when the user clicks a button, the button triggers an event. You, the JSF programmer, decide what the JSF application will do when a particular event is fired. You do this by writing event listeners. In other words, a JSF application is event-driven. Figure 1 illustrates the processing of a JSF application.
When an event occurs (say, when the user clicks a button), the event notification is sent via HTTP to the server. On the server is a special servlet called the FacesServlet. Each JSF application in the Web container has its own FacesServlet.
In the background, three things happen for each JSF request, as illustrated in Figure 2.
For JSF requests to be processed, they must be directed to a servlet called FacesServlet. The redirection is accomplished by using the following servlet and servlet-mapping tags in the deployment descriptor:
<servlet>
<servlet-name>Faces Servletservlet-name>
<servlet-class>javax.faces.webapp.FacesServletservlet-class>
<load-on-startup>1load-on-startup>
servlet>
<servlet-mapping>
<servlet-name>Faces Servletservlet-name>
<url-pattern>/faces
This means that the URL of every request must contain the /faces/ pattern, as specified in the url-pattern element under the servlet-mapping element.
Figure 1 JSF applications are event-driven
NOTE You can specify a context parameter saveStateInClient with a value of true to force JSF to save state in the client as opposed to saving it in the server. If you choose to do so, you must add the following context-param element before the servlet element in your deployment descriptor.
<context-param>
<param-name>saveStateInClientparam-name>
<param-value>falseparam-value>
context-param>
FacesServlet creates an object called FacesContext, which contains information necessary for request processing. To be more precise, FacesContext contains the ServletContext, ServletRequest, and ServletResponse objects that are passed to the service method of FacesServlet by the Web container. During processing, FacesContext is the object that is modified.
Figure 2 How JSF works in a nutshell
Next is the processing. The processor is an object called Lifecycle. The FacesServlet servlet hands over control to the Lifecycle object. The Lifecycle object processes the FacesContext object in six phases, which we will look at next.
NOTE The series of actions necessary for JSF request processing by the Lifecycle object is referred to as the request processing lifecycle. You will encounter this term throughout this book.
JSF also allows you to configure a JSF application via an application configuration file. After discussing the Lifecycle object phases, we will discuss how to use this configuration file to register JavaBeans.
JSF Lifecycle
Figure 3 The JSF lifecycle
Phase 1: Restore view
In the first phase of the JSF lifecycle -- restore view -- a request comes through the FacesServlet controller. The controller examines the request and extracts the view ID, which is determined by the name of the JSP page.
The JSF framework controller uses the view ID to look up the components for the current view. If the view doesn't already exist, the JSF controller creates it. If the view already exists, the JSF controller uses it. The view contains all the GUI components.
This phase of the lifecycle presents three view instances: new view, initial view, and postback, with each one being handled differently. In the case of a new view, JSF builds the view of the Faces page and wires the event handlers and validators to the components. The view is saved in a FacesContext object.
The FacesContext object contains all the state information JSF needs to manage the GUI component's state for the current request in the current session. The FacesContext stores the view in its viewRoot property; viewRoot contains all the JSF components for the current view ID.
In the case of an initial view (the first time a page is loaded), JSF creates an empty view. The empty view will be populated as the user causes events to occur. From an initial view, JSF advances directly to the render response phase.
In the case of a postback (the user returns to a page she has previously accessed), the view corresponding to the page already exists, so it needs only to be restored. In this case, JSF uses the existing view's state information to reconstruct its state. The next phase after a postback is apply request values.
Phase 2: Apply request values
The purpose of the apply request values phase is for each component to retrieve its current state. The components must first be retrieved or created from the FacesContext object, followed by their values. Component values are typically retrieved from the request parameters, although they can also be retrieved from cookies or headers.
If a component's immediate event handling property is not set to true, the values are just converted. So if the field is bound to an Integer property, the value is converted to an Integer. If the value conversion fails, an error message is generated and queued in the FacesContext, where it will be displayed during the render response phase, along with any validation errors.
If a component's immediate event handling property is set to true, the values are converted to the proper type and validated. The converted value is then stored in the component. If the value conversion or value validation fails, an error message is generated and queued in the FacesContext, where it will be displayed during the render response phase, along with any other validation errors.
Phase 3: Process validation
The first event handling of the lifecycle takes place after the apply request values phase. At this stage, each component will have its values validated against the application's validation rules. The validation rules can be pre-defined (shipped with JSF) or defined by the developer. Values entered by the user are compared to the validation rules. If an entered value is invalid, an error message is added to FacesContext, and the component is marked invalid. If a component is marked invalid, JSF advances to the render response phase, which will display the current view with the validation error messages. If there are no validation errors, JSF advances to the update model values phase.
Phase 4: Update model values
The fourth phase of the JSF application lifecycle -- update model values -- updates the actual values of the server-side model -- namely, by updating the properties of your backing beans (also known as managed beans). Only bean properties that are bound to a component's value will be updated. Notice that this phase happens after validation, so you can be sure that the values copied to your bean's properties are valid (at least at the form-field level; they may still be invalid at the business-rule level).
Phase 5: Invoke application
At the fifth phase of the lifecycle -- invoke application -- the JSF controller invokes the application to handle Form submissions. The component values will have been converted, validated, and applied to the model objects, so you can now use them to execute the application's business logic.
At this phase, you also get to specify the next logical view for a given sequence or number of possible sequences. You do this by defining a specific outcome for a successful form submission and returning that outcome. For example: on successful outcome, move the user to the next page. For this navigation to work, you will have to create a mapping to the successful outcome as a navigation rule in the faces-config.xml file. Once the navigation occurs, you move to the final phase of the lifecycle.
Phase 6: Render response
In the sixth phase of the lifecycle -- render response -- you display the view with all of its components in their current state.
Figure 2 is an object state diagram of the six phases of the JSF lifecycle, including validation and event handling.
Figure 4 The six-phase progression of the JSF lifecycle
A simple JSF application
A JSF application is just like any other Java Web application. It runs in a servlet
container, and it typically contains:
- JSP pages
- Event listeners
- Java Beans that hold data and application-specific functionality
- Server-side classes, such as database access beans
In addition to these common items, a JSF application also has:
- A custom tag library for rendering UI components on a page. This is called the component tag library, and it is provided by the JSF implementation. The component tag library eliminates the need to hardcode UI components in any specific markup language, such as HTML. This results in completely reusable UI components.
- A custom tag library for representing event handlers, validators and other actions. This is called the core tag library, and it is provided by the JSF implementation. The core tag library makes it easy to register events, validators and actions on the components.
- UI components represented as stateful objects on the server.
- Backing beans, which define properties and functions for UI components.
- Validators, converters, event listeners and event handlers.
- An application configuration resource file for configuring application resources.
Example: Product Display Application
A simple product display application that accesses a list of plants from a supplier backend. When selecting a plant from the list, you will be directed to one of three pages:
- An error page if a product is not carried at all
- A backordered product page that might display information on dealing with that issue or
- A product detail page for items in stock and ready for ordering
The following link gives the steps to be followed in creating the example.
http://www.ibm.com/developerworks/rational/library/04/r-3219/
A simple JSF Portlet Application
The JSF portlet runtime is the component that makes possible to run JSF
applications as portlets in WebSphere Portal. The JSF portlet runtime is found in
a different jar file for each portlet API:
- For the JSR 168 API, the jar file is jsf-portlet.jar.
- For the IBM Portlet API, the jar file is jsf-wp.jar.
Besides this, the application makes use of portlet.xml, in addition to faces-config.xml and web.xml
Example: The calculator application
The first application to be created is a simple calculator. A JavaBean named
CalculatorBean is included to provide the basic mathematical operations on two
integer (long) numbers.
This bean has five properties:
_ Operand 1
_ Operand 2
_ Operation
_ Result
_ Error message
The bean also has associated getter and setter methods for all of its properties.
In addition, the calculate() method calculates the result of one of the following
operations:
_ Add
_ Subtract
_ Multiply
_ Divide
The result is stored in the first number (operand 1) for subsequent operations. If
a division does not result in an integer, an exception is thrown. Finally, a
toString() method displays the numbers and the operation.
The following is the link:
http://www.redbooks.ibm.com/Redbooks.nsf/RedbookAbstracts/sg246449.html
Here you need to download the PDF file.
Chapter 17 gives the steps to be followed in creating the application
References
http://www.devshed.com/c/a/Java/Introduction-to-JavaServer-Faces-1/
http://www.ibm.com/developerworks/library/j-jsf2/
Click here to View more...
