Home arrow Java arrow Page 4 - JSF Development Process Overview

JSF Development Process Overview

This article outlines the steps involved in creating an application using JavaServer Faces. It is excerpted from chapter two of the book JavaServer Faces, written by  by Hans Bergsten (O'Reilly, 2004; ISBN: 0596005393).

Author Info:
By: O'Reilly Media
Rating: 4 stars4 stars4 stars4 stars4 stars / 8
October 13, 2005
  1. · JSF Development Process Overview
  2. · Developing an Application with a JSF-Based User Interface
  3. · Developing Components and Integration Code
  4. · Developing the User Interface Pages

print this article

JSF Development Process Overview - Developing the User Interface Pages
(Page 4 of 4 )

With the Java classes defined and implemented in some form (maybe just prototypes initially), the page author can get to work.

The page author is the person who is responsible for developing the pages that make up the applicationís user interface, typically as templates that interleave static content (text, graphics, tables for layout, and so on) with dynamically generated content. A page is represented by a set of UI component instances bound to the applicationís data and methods. The static content and the dynamic content generated by the components is combined and sent to the browser. When the user clicks a link or a button in the page, the request is processed by the methods bound to the UI components. Depending on the outcome, the same page may be rendered again or the application may select a new page to send back to the user.

As I mentioned earlier, JSF can be combined with different presentation layer technologies, so the details of what the template looks like may vary depending on the options supported by the JSF implementation. For better or for worse, JSF 1.0 requires all implementations to support JSP as one of the possible presentation layer technologies. On one hand, JSP is familiar to many developers, so it lowers the barrier of entry to JSF. On the other hand, JSP has its own mechanism for adding dynamic content to a static template; when mixed with JSF UI components, thereís a risk for confusion and clashes between the two technologies. I use JSP for the newsletter application and for most of the other examples in this book, but you should be aware that itís not the only option. Donít worry too much about the potential clashes between JSP and JSF. Iíll explain the issues and show you how to steer clear of the potential problems as we encounter them.

When JSP is used as the presentation layer technology, the page author creates a JSP page with the static content plus special elements that represent JSF components. Example 2-1 shows a JSP page with JSF elements for the newsletter subscription form.

Example 2-1. JSP page with JSF elements for the subscription form (newsservice/subscribe.jsp)

<%@ taglib uri="http://java.sun.com/jsf/html" prefix="h" %>
<%@ taglib uri="http://java.sun.com/jsf/core" prefix="f" %>
<title>Newsletter Subscription</title>
           <td>Email Address:</td>
<h:inputText value="#{subscr.emailAddr}" /> 
<td>News Letters:</td>
          <h:selectManyCheckbox value="#{subscr.subscriptionIds}"> 
            <f:selectItem itemValue="1" itemLabel="JSF News" />
            <f:selectItem itemValue="2" itemLabel="IT Industry News" />   
            <f:selectItem itemValue="3" itemLabel="Company News" /> 

<h:commandButton value="Save" 
         action="#{subscrHandler.saveSubscriber}" />  

At the beginning of Example 2-1, you find two JSP custom tag library declarations. If youíre not familiar with JSP, donít worry. Iíll explain what you need to know in Chapter 4. For now, just accept that these declarations identify all elements with the specified prefixes as special JSF elements. Elements with the prefix h(short for HTML) represents the standard JSF UI components combined with HTML renderers; elements with the prefixf(short for Faces) represent validators, event listeners, etc. that can be attached to the UI components.

Following the custom tag library declarations, there are HTML elements for layout and JSF elements corresponding to the JSF UI components. Ignoring the<f:view>element for now, the first JSF element of interest is the<h:form>element, representing a JSF form component. The same as in HTML, JSF input components must always be nested within a form component.

The email address input component is represented by the<h:inputText>element. Thevalueattribute contains a value binding expression that binds the component to theemailAddrproperty of an application bean namedsubscr. As you may recall, this is the name assigned to theSubscriberbean in the JSF configuration file. The list of newsletter choices is represented by an<h:selectManyCheckbox>element with a nested<f:selectItem>element for each choice. The<h:selectManyCheckbox>elementvalueattribute is set to a value expression that binds the component to thesubscriptionIdsproperty of theSubscriberbean available through thesubscrvariable.

Finally, thereís an<h:commandButton>element representing the Save button, with anactionattribute containing a method binding expression that binds it to thesaveSubscriber()method of theSubscriberHandlerbean available through thesubscrHandlervariable.

Figure 2-3 illustrates what happens when a user requests the JSP page for the first time, and how the value and method binding expressions for the JSF elements in the JSP page combined with the bean declarations in the faces-config.xml file ties the whole thing together.


Figure 2-3.  Object creation when processing the JSP
                              page the first time

When the<h:textInput>element is processed, the correspondingUIInputcomponent is created and bound to the bean property specified by the value binding expression. The component is then asked to render itself. It evaluates the value binding expression and, if the bean doesnít already exist, JSF creates it based on the information in the faces-config.xml file. The input component pulls its value from the property of the bean specified by the rest of the value binding expression and uses it as the value of the HTML<input>element it renders. The other JSF elements are processed in the same way, and the combination of static content and the content generated by the JSF components is sent to the browser.

When the user enters values in the form and clicks the Submit button, JSF processes the request by asking each component to get its value from the request. Each input component sets the bean property itís bound to, and the command component fires an event that causes the method itís bound to be invoked. The method typically saves the new values to a database or does some other backend processing, but in this simple example, as you may recall, it just writes the values to the console.

JSF then creates a response by processing the same or another JSP page (depending on the event processing methodís return value and configuration-options we havenít talked about yet). If the same page is used, the component and application objects already exist, so no new objects are created. Other than that, the JSP page is processed exactly as for the first request.

This is a very simplified description of what really occurs at runtime. As you will learn, thereís a lot more that may happen when a form is submitted, such as input value conversion and validation, error message queuing, forced redisplay of the same page without updating any bean properties, and more. But Iíve tried to keep it simple in this chapter to help you understand the basics of how the application code and the JSF components fit together. If youíre still feeling dazed and confused after this whirlwind tour through the JSF architecture and the request processing, thatís okay. Things will clear up when we go through all of this again, step-by-step and in more detail in the following chapters.

DISCLAIMER: The content provided in this article is not warranted or guaranteed by Developer Shed, Inc. The content provided is intended for entertainment and/or educational purposes in order to introduce to the reader key ideas, concepts, and/or product reviews. As such it is incumbent upon the reader to employ real-world tactics for security and implementation of best practices. We are not liable for any negative consequences that may result from implementing any information covered in our articles or tutorials. If this is a hardware review, it is not recommended to open and/or modify your hardware.

blog comments powered by Disqus

- Java Too Insecure, Says Microsoft Researcher
- Google Beats Oracle in Java Ruling
- Deploying Multiple Java Applets as One
- Deploying Java Applets
- Understanding Deployment Frameworks
- Database Programming in Java Using JDBC
- Extension Interfaces and SAX
- Entities, Handlers and SAX
- Advanced SAX
- Conversions and Java Print Streams
- Formatters and Java Print Streams
- Java Print Streams
- Wildcards, Arrays, and Generics in Java
- Wildcards and Generic Methods in Java
- Finishing the Project: Java Web Development ...

Watch our Tech Videos 
Dev Articles Forums 
 RSS  Articles
 RSS  Forums
 RSS  All Feeds
Write For Us 
Weekly Newsletter
Developer Updates  
Free Website Content 
Contact Us 
Site Map 
Privacy Policy 

Developer Shed Affiliates


© 2003-2019 by Developer Shed. All rights reserved. DS Cluster - Follow our Sitemap
Popular Web Development Topics
All Web Development Tutorials