Introduction to JavaServer Faces, Part 1

This chapter gently introduces the JavaServer Faces technology. More importantly, it teaches you how to write your first JSF application to get a feel for how this great technology works.  In addition to the sample chapters, this chapter prepares you for the next chapters by introducing the JSF Application Programming Interface (API) and the Application Configuration file. This excerpt comes from chapter two of JavaServer Faces Programming, by Budi Kurniawan (McGraw-Hill/Osborne, ISBN 0-07-222983-7, 2004).

Intro to JavaServer FacesA 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.

In this chapter, you will get an overview of how JSF works and the steps to writing a simple JSF application. Then you will put this knowledge to use by working through three examples. Finally, you will be introduced to the JSF Application Programming Interface (API).

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:

[code]
<!– Faces Servlet –>
<servlet>
  <servlet-name>Faces Servlet</servlet-name>
  <servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
  <load-on-startup>1</load-on-startup>
</servlet>
<!– Faces Servlet Mapping –>
<servlet-mapping>
  <servlet-name>Faces Servlet</servlet-name>
  <url-pattern>/faces/*</url-pattern>
</servlet-mapping>
[/code]

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. 

JSF Applications

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.

[code]
<context-param>
  <param-name>saveStateInClient</param-name>
  <param-value>false</param-value>
</context-param>
[/code]

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. 

JSF

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.

Buy this book now!Remember: This is part one of the second chapter of JavaServer Faces Programming, by Budi Kurniawan (McGraw-Hill/Osborne, ISBN 0-07-222983). Stay tuned for part 2 of “Introduction to JavaServer Faces (JSF),” where we learn about JSP, JavaBeans, and Model 2.
Buy this book!

{mospagebreak title=Understanding the Request Processing Lifecycle Phases}

The Lifecycle object processes a JSF request (encapsulated in the FacesContext object; the FacesContext is the object that is read and modified by Lifecycle during processing) in six phases, executed in the following order:


  • Reconstitute Component Tree
    A JSP page in a JSF application is represented by a component tree. This phase starts the Lifecycle request processing by constructing this tree. Each component tree has an identifier that is unique throughout the application. The identifier of a component tree is the path information portion of the request URI. For a request with the URI /faces/index.jsp, for instance, the tree identifier is /index.jsp. The constructed component tree is then saved in the FacesContext object for processing by the following request processing phases.

  • Apply Request Values
    In this phase, the local value of each component in the component tree is updated from the current request. A value can come from a request parameter, a header, a cookie, and so on. During this phase, a component may queue events. These events will be processed during the process event steps in the request processing lifecycle.

  • Process Validations
    After the local value of each component is updated, in the Process Validations phase, the Lifecycle object will validate those values if necessary. A component that requires validation must provide implementation of the validation logic. Alternatively, a JSF programmer can register zero or more validators with the component. If one or more external validators are found, the local value of each component will be validated using the validation logic in these external validators.

  • Update Model Values
    This phase can be reached only if the local values of all components in the tree are valid. In this phase, the Lifecycle object updates the application’s model data. During this phase, a component may again queue events.

  • Invoke Application
    During this phase, the JSF implementation handles any application level events, such as submitting a form or linking to another page.

  • Render Response
    In this phase, the JSF implementation renders the response to the client.
The Apply Request Values, Process Validations, Update Model Values, and Invoke Application phases in the request processing lifecycle may queue events in the FacesContext instance associated with the current request. Therefore, the JSF implementation must handle these events after these phases.

Between two phases, the Lifecycle object checks any event listener that needs to be called. When writing an event listener, you can choose after which phase the listener should be executed. Alternatively, you can write an event listener that is called after various phases.

Figure 3 illustrates the processing of a JSF request through these phases. The smaller boxes that are labeled “Process Events” indicate the steps that the Lifecycle object takes to execute event listeners. 

JSF phases

Figure 3 The phases of the request processing lifecycle

Note that an event listener can change the course of the processing flow by indicating to the Lifecycle object that the processing should jump to the last phase or be terminated immediately after the current event processing.

Buy this book now!Remember: This is part one of the second chapter of JavaServer Faces Programming, by Budi Kurniawan (McGraw-Hill/Osborne, ISBN 0-07-222983). Stay tuned for part 2 of “Introduction to JavaServer Faces (JSF),” where we learn about JSP, JavaBeans, and Model 2.
Buy this book!

{mospagebreak title=Using an Application Configuration File}

You can easily configure a JSF application via an application configuration file. In this file, you can register JavaBeans used in the application, define the program-control flow by specifying page-navigation rules, register custom components, and perform other configuration tasks.

The application configuration file is an XML file and can be declared in several places. The easiest way to use this file is to put it in the WEB-INF directory and call it faces-config.xml.

The root element of an application configuration file is faces-config. Here is the skeleton of an application configuration file:

[code]
<?xml version=”1.0″? >
<!DOCTYPE faces-config PUBLIC
  “-//Sun Microsystems, Inc.//DTD JavaServer Faces Config 1.0//EN”
  “http://java.sun.com/dtd/web-facesconfig_1_0.dtd”>

 

<faces-config>
</faces-config>
[/code]

There are a number of aspects of a JSF application that can be configured in the application configuration file. Here, we will focus on how to register JavaBeans (as used in the examples later in this chapter). The application configuration file is explained in detail in Chapter 15.

In a JSP page, you can use the jsp:useBean action to tell the JSP container that you are using the JavaBean class specified in the class attribute of the jsp:useBean action, such as the following:

[code]
<jsp:useBean id=”numberBean” class=”ch02.NumberBean”
scope=”session” />
[/code]

This tells the Web container to load the JavaBean class and create an instance of it when the JSP page is called. The jsp:useBean action needs to be declared in only one page, and it will be usable in all the JSP pages in the same application. A JSF application allows you to do this instead of registering a JavaBean in the application configuration file.

However, there is a drawback when using <jsp:useBean>. If a page other than the one containing the jsp:useBean action is called before the page that does use the element is called, the Web container will throw an exception. This is because the other page is trying to use a JavaBean that has not been created. If you register the JavaBean in the application configuration file, you will not have this problem.

For each JavaBean you want to register in the application configuration file, you use the managed-bean tag inside the faces-config element. Inside the managed-bean element, you have the following subelements:

  • The managed-bean-name tag defines a name to refer to the JavaBean from a JSP page.
  • The managed-bean-class element specifies the JavaBean class.
  • The managed-bean-scope element defines the scope of the JavaBean.

Here is an example of a managed-bean element:

[code]
<managed-bean>
  <managed-bean-name>myBean</managed-bean-name>
  <managed-bean-class>myPackage.MyBean</managed-bean-class>
  <managed-bean-scope>session</managed-bean-scope>
</managed-bean>
[/code]

The managed-bean element in this example is of type myPackage.MyBean and can be referred to as MyBean from any JSP page in the JSF application. The scope of the bean is session, meaning that an instance of this bean is created at the beginning of a user session. The managed-bean element will be explained further in Chapter 3.

Later in this chapter, in the “Creating the Page Navigation Example” section, you will see how to use an application configuration file to define page-navigation rules in a JSF application with many pages.

Buy this book now!Remember: This is part one of the second chapter of JavaServer Faces Programming, by Budi Kurniawan (McGraw-Hill/Osborne, ISBN 0-07-222983). Stay tuned for part 2 of “Introduction to JavaServer Faces (JSF),” where we learn about JSP, JavaBeans, and Model 2. 
Buy this book!

{mospagebreak title=Writing a JSF Application}

Building a JSF application requires the following three steps:

  • Author JSP pages, using custom tags representing JSF components that will be rendered as HTML elements.
  • Write JavaBeans as the state holder of the user input and components’ data. A component can be bound with a JavaBean. In this case, the component’s local value will be copied to the JavaBean’s property if the local value is valid.
  • Write an event listener that determines what should happen when an event occurs, such as when the user clicks a button or submits a form. JSF supports two events: ActionEvent and ValueChangedEvent. ActionEvent is fired when the user submits a form or clicks a button, and ValueChangedEvent is triggered when a value in a JSF component changes.

NOTE The JSF implementation also provides a default event listener for page navigation that can be configured easily. You should not write an event listener that tampers with page navigation.

These steps do not need to happen in a particular order. In fact, they can occur simultaneously in a project with a clear separation of labor. Now, let’s take a closer look at each of these three steps. 

Authoring JSP Pages

Authoring a JSP page requires you to be familiar with the standard JSF components. JSF components are discussed in detail in Chapters 4 and 5. The following components are used in the examples in this chapter: 

  • The UIForm component is rendered as an HTML form.
  • The UIInput component is rendered as an input field to accept user input.
  • The UIOutput component is rendered as normal HTML text and is used for displaying output.
  • The UICommand component is rendered as a button.

In a JSP page, you use custom tags that represent JSF components. These custom tags are part of two custom tag libraries, HTML and Core, and are included in the WEB-INF/lib directory of the application directory (as discussed in the “Introduction” to this book). The tag library descriptors (TLD files) for these libraries have also been included in the .jar files, so you do not need to worry about them.

To use the custom tags that represent JSF components, you need the following two taglib directives on top of every JSP page in the JSF application:

[code]
<%@ taglib uri=”http://java.sun.com/jsf/html” prefix=”h” %>
<%@ taglib uri=”http://java.sun.com/jsf/core” prefix=”f” %>
[/code]

All custom tags representing the component must be enclosed in the use_faces tags of the Core custom tag library:

[code]
<f:use_faces>
<%– custom tags representing JSF components here –%>
</f:use_faces>
<%-- custom tags representing JSF components here --%>[/code]

The custom tags representing JSF components are discussed in Chapters 4 and 5. The following are some of the custom tags used in the examples in this chapter:

  • <h:form> represents a UIForm component.
  • <h:input_text> represents a UIInput component that accepts any text.
  • <h:input_number> represents a UIInput component that accepts a number.
  • <h:output_text> represents a UIOutput component that displays any text.
  • <h:output_number> represents a UIOutput component that displays a number.
  • <h:output_errors> represents a UIOutput component that displays error messages that occurred during the request processing.
  • <h:command_button> represents a UICommand component.
  • <f:action_listener> represents an ActionListener.
  • <f:valuechanged_listener> represents a ValueChangedListener.
  • <f:validator> represents a validator.

Buy this book now!Remember: This is part one of the second chapter of JavaServer Faces Programming, by Budi Kurniawan (McGraw-Hill/Osborne, ISBN 0-07-222983). Stay tuned for part 2 of “Introduction to JavaServer Faces,” where we learn about JSP, JavaBeans, and Model 2.
Buy this book!

{mospagebreak title=Writing JavaBeans and Event Listeners}

Writing JavaBeans

As noted earlier, you can bind a component to a JavaBean. In this case, the component’s local value will be copied to the JavaBean’s property if the local value is valid. To bind a component to a JavaBean’s property, you use the valueRef attribute in the custom tag representing the component. For example, to bind a UIOutput component so that it can retrieve its value from the result property of a JavaBean called testingBean, use the following:

[code]
<h:output_text valueRef=”testingBean.result”/>
[/code]

Writing Event Listeners

Because JSF applications are event-driven, you need to write event listeners to determine how your applications will behave. You need to register any event listener that you want to be notified when an event is triggered by a component. To register an ActionListener with a component such as a UICommand, use the action_listener tag of the Core custom tag library inside the custom tag representing the component:

[code]
<h:command_button id=”submitButton” label=”Add”
  commandName=”submit” >
  <f:action_listener type=”ch02a.MyActionListener” />
</h:command_button>
[/code]

You must also write your listener class by implementing the javax.faces.event. ActionListener interface or the javax.faces.event.ValueChangedListener interfaces.

Events and listeners are discussed in more detail in Chapter 7.

Buy this book now!Remember: This is part one of the second chapter of JavaServer Faces Programming, by Budi Kurniawan (McGraw-Hill/Osborne, ISBN 0-07-222983). Stay tuned for part 2 of “Introduction to JavaServer Faces,” where we learn about JSP, JavaBeans, and Model 2. 
Buy this book!

{mospagebreak title=Creating the Event Listener and Component Tree Example}

The example presented in this section illustrates the process of developing a simple JSF application. It demonstrates how to write a JSF application with an event listener that is executed when the user clicks a button. The event listener simply prints the names of the components in the component tree.

The application consists of a JSP page that has a form with two input fields to accept two numbers and print the result of the addition of the two numbers. There is also a button that, when clicked, fires an ActionEvent and causes an event listener to be executed.

The page has five user interface (UI) components: a UIForm component, two UIInput components, a UIOutput component, and a UICommand component (these are described in the previous section). The UIInput components and the UIOutput component are bound to a JavaBean that stores the two input values and contains the logic of the addition.

As explained earlier in this chapter, the request processing lifecycle always begins with the Reconstitute Component Tree phase. In this phase, the Lifecycle object builds the component tree representing the requested page. This example shows how a component tree looks conceptually. To be able to draw the tree, you need to create an event listener that will be called during one of the process event steps in the request processing lifecycle.

The application consists of the following:

  • A JSP page named adder.jsp
  • A NumberBean JavaBean for storing user data
  • An action listener called MyActionListener
  • A deployment descriptor (web.xml)
  • An application configuration file for registering the JavaBean

For your JSF application to work, it needs a set of .jar files containing the JSF reference implementation and other libraries. See the “Introduction” of this book for the list of all libraries you need to include in your JSF application.

NOTE Don’t worry if you don’t fully understand the code used in the application examples in this chapter. The code will be explained in later chapters.

Buy this book now!Remember: This is part one of the second chapter of JavaServer Faces Programming, by Budi Kurniawan (McGraw-Hill/Osborne, ISBN 0-07-222983). Stay tuned for part 2 of “Introduction to JavaServer Faces,” where we learn about JSP, JavaBeans, and Model 2. 
Buy this book!

{mospagebreak title=Creating the Directory Structure}

As the first step, you need to create a directory structure for your JSF application. In Tomcat, you create this under webapps. The directory structure for your application, called JSFCh02a, is depicted in Figure 4. The directory contains all the required components that you will build in this example.

First, note that you must copy the .jar files containing the JSF implementation into the WEB-INF/lib directory. Then, in the WEB-INF/classes directory, you have the JavaBean class. In the WEB-INF directory, you have the deployment descriptor (web.xml) and the application configuration file (faces-config.xml). Lastly, the adder.jsp page is in the application directory itself.

Writing the Deployment Descriptor for the Listener and Component Tree Example

Just like any other servlet/JSP application, this JSF application needs a deployment descriptor. Listing 1 presents the deployment descriptor for this application.

JSF structure

Figure 4 The directory structure of the listener and
component tree example

Listing 1 The Deployment Descriptor (web.xml)

[code]
<?xml version=”1.0″? >
<!DOCTYPE web-app PUBLIC
  “-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN”
  “http://java.sun.com/dtd/web-app_2_3.dtd”>

 

<web-app>
  <!– Faces Servlet –>
  <servlet>
    <servlet-name>Faces Servlet</servlet-name>
    <servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
    <load-on-startup> 1 </load-on-startup>
  </servlet>

 

  <!– Faces Servlet Mapping –>
  <servlet-mapping>
    <servlet-name>Faces Servlet</servlet-name>
    <url-pattern>/faces/*</url-pattern>
  </servlet-mapping>
</web-app>
[/code]

There are two sections in the deployment descriptor. The servlet element registers the FacesServlet, and the servlet-mapping element states that any request containing the pattern /faces/ in the URL must be passed to the FacesServlet

Buy this book now!Remember: This is part one of the second chapter of JavaServer Faces Programming, by Budi Kurniawan (McGraw-Hill/Osborne, ISBN 0-07-222983). Stay tuned for part 2 of “Introduction to JavaServer Faces,” where we learn about JSP, JavaBeans, and Model 2. 
Buy this book!

{mospagebreak title=Writing the Object Model for the Listener and Component Tree Example}

For this application, you need a JavaBean to store the two numbers to add and the result of the addition. Listing 2 presents the JavaBean called NumberBean.

Listing 2 The NumberBean JavaBean

[code]
package ch02a;
public class NumberBean {
  int firstNumber = 0;
  int secondNumber = 0;
  public NumberBean () { 
    System.out.println(“Creating NumberBean”);
  }
  public void setFirstNumber(int number) {
    firstNumber = number;
    System.out.println(“setFirstNumber: ” + number);
  }
  public int getFirstNumber() {
    System.out.println(“getFirstNumber: ” + firstNumber);
    return firstNumber;
  } 
  public void setSecondNumber(int number) {
    secondNumber = number;
    System.out.println(“setSecondNumber: ” + number);
  } 
  public int getSecondNumber() {
    System.out.println(“getSecondNumber: ” + secondNumber);
    return secondNumber;
  } 
  public int getResult() {
    System.out.println(“getResult ” + (firstNumber + secondNumber));
    return firstNumber + secondNumber;
 }
}
[/code]

Writing the Application Configuration File

As explained earlier in the chapter, the best way to make the JavaBean available to the JSF application is to register it in the application configuration file. Listing 3 shows the application configuration file (faces-config.xml) needed by the application. 

Listing 3 The Application Configuration File (faces-config.xml) for the Listener and Component Tree Example

[code]
<?xml version=”1.0″? >
<!DOCTYPE faces-config PUBLIC
  “-//Sun Microsystems, Inc.//DTD JavaServer Faces Config 1.0//EN”
  “http://java.sun.com/dtd/web-facesconfig_1_0.dtd”>

 

<faces-config>
  <managed-bean>
    <managed-bean-name>numberBean</managed-bean-name>
    <managed-bean-class>ch02a.NumberBean</managed-bean-class>
    <managed-bean-scope>session</managed-bean-scope>
  </managed-bean>
</faces-config>
[/code]

Authoring the JSP Page for the Listener and Component Tree Example

For the user interface, you need a JSP page called adder.jsp, which is shown in Listing 4.

Listing 4 The adder.jsp Page

[code]<%@ taglib uri="http://java.sun.com/jsf/html" prefix="h" %><%@ taglib uri="http://java.sun.com/jsf/core" prefix="f" %>
<%@ taglib uri=”http://java.sun.com/jsf/html” prefix=”h” %>
<%@ taglib uri=”http://java.sun.com/jsf/core” prefix=”f” %>
<html>
<head>
<title>Add 2 numbers</title>
</head>
<body>
<f:use_faces>
<h:form formName=”addForm” >
  <br/>First Number:
  <h:input_number id=”firstNumber”
    valueRef=”numberBean.firstNumber”/>
  <br/>Second Number:
  <h:input_number id=”secondNumber”
    valueRef=”numberBean.secondNumber”/>
  <br/>Result:
  <h:output_number id=”output” valueRef=”NumberBean.result”/>
  <br/>
  <h:command_button id=”submitButton” label=”Add”
    commandName=”submit” >
    <f:action_listener type=”ch02a.MyActionListener” />
  </h:command_button>
</h:form>
</f:use_faces>
</body>
</html>
[/code]

Buy this book now!Remember: This is part one of the second chapter of JavaServer Faces Programming, by Budi Kurniawan (McGraw-Hill/Osborne, ISBN 0-07-222983). Stay tuned for part 2 of “Introduction to JavaServer Faces,” where we learn about JSP, JavaBeans, and Model 2. 
Buy this book!

{mospagebreak title=Defining Taglib Directives}

First, you define two taglib directives to use the two JSF tag libraries: HTML and Core. The tag library descriptors for these two libraries can be found in the jsf-ri.jar file, so you do not need to worry about them. The prefix for the HTML tag library is h, and the prefix for the Core tag library is f.

[code]
<%@ taglib uri=”http://java.sun.com/jsf/html” prefix=”h” %>
<%@ taglib uri=”http://java.sun.com/jsf/core” prefix=”f” %>
[/code]

<%@ taglib uri="http://java.sun.com/jsf/html" prefix="h" %><%@ taglib uri="http://java.sun.com/jsf/core" prefix="f" %>Next are the JSF controls. Note that JSF controls must be enclosed in the opening and closing elements:

[code]
<f:use_faces>

</f:use_faces>
[/code]
Inside these elements, you have a form:
[code]
 <h:form formName=”addForm”>

</h:form>
[/code]

Nested inside the form are two input_number controls, an output_number control, and a command_button control.

[code]
<br/>First Number:
<h:input_number id=”firstNumber”
  valueRef=”numberBean.firstNumber”/>
<br/>Second Number:
<h:input_number id=”secondNumber”
  valueRef=”numberBean.secondNumber”/>
<br/>Result:
<h:output_number id=”output” valueRef=”NumberBean.result”/>
<br/>
<h:command_button id=”submitButton” label=”Add”
  commandName=”submit” >
<f:action_listener type=”ch02a.MyActionListener” />
</h:command_button>
[/code]

Notice the ActionListener for the command button.

The component tree

Figure 5
The component tree of the adder.jsp page

Conceptually, the component tree for this JSP page is depicted in Figure 5, with the root omitted. The main component is the form, and the form has four child components.

Buy this book now!Remember: This is part one of the second chapter of JavaServer Faces Programming, by Budi Kurniawan (McGraw-Hill/Osborne, ISBN 0-07-222983). Stay tuned for part 2 of “Introduction to JavaServer Faces,” where we learn about JSP, JavaBeans, and Model 2. 
Buy this book!
[gp-comments width="770" linklove="off" ]

chat sex hikayeleri Ensest hikaye