Mastering JavaServer™ Face phần 5 pps

If the user changes the value of one of the components and the valuepasses all the validations, the JSF runtime will set the value on the user object using the setPassword method during

The UIPanel is used to manage the layout of the rest of the components.The children of the panel are arranged in a grid two columns wide and asmany rows as needed to make room for all the child components In otherwords, since the columns attribute is set for this panel, two components at atime will be placed into a row, then a new row will be created for the next two,until there are no more child components The grid Renderer creates an HTML

<table>element for the UIPanel component The panel renders its children

so that it can manage the layout by rendering the components inside the rowsand cells of the table Here is the code for the opening of the panelGrid tagfrom Listing 5.4 for quick reference

<h:panelGrid id=”registrationPanel” columns=”2”

rowClasses=”centered”

footerClass=”centered” border=”1”>

The rowClasses attribute specifies the CSS classes to apply to each row.The Renderer will apply the value specified in this attribute to every row in thetable If you’d like to alternate colors or some other aspect of the row, you cancomma-delimit the different CSS classes in this attribute For example, if youwanted every other row to have a gray background, you could specify thevalue of rowClasses like this:

<h:panelGrid id=”registrationPanel” columns=”2”

rowClasses=”centered, grayCentered”

footerClass=”grayCentered” border=”1”>

The table will be rendered with every other row having its class set tograyCentered Figure 5.6 shows the page rendered with every other row ingray

Figure 5.6 Row class example.

The next block of code from Listing 5.4 creates the UIOutput and UIInputcomponents that allow the users to enter their information for registration.There are four UIOutput components that make up the labels and four UIIn-put components that make up the text fields Let’s look in detail at the pass-word entry label and text field component pair to get a better understanding

of how these tags work Here is the code for the components:

The UIInput component has its value set to user.password It is tant that you understand the value attribute and how it works to use theJSF/JSP integration effectively The model reference can be thought of as apath through your objects In this case, the root of the path is user, which isspecified in the faces-config.xml file Essentially, the object becomes visi-ble as a local variable on this page when it is used; the managed bean mecha-nism will create the object if it is not already present The mechanism works alot like the jsp:useBean tag If the bean is already present in the scope spec-ified, then the tag will do nothing; otherwise, it will create the bean The nextpart of the path is password This is a property of the user object, and it isassumed that there is an accessor pair for that property that follows the Jav-aBean naming convention (that is, there is a get/setPassword method pair

impor-on the user bean) The JSF runtime will get the value used to display this ponent from the model with the getPassword method (since this is a secretUIInput, it will not display the characters though) during the Render Response

com-phase If the user changes the value of one of the components and the valuepasses all the validations, the JSF runtime will set the value on the user object

using the setPassword method during the Update Model Values phase.

The next section of this JSP, from Listing 5.4 again, is the footer facet A facet is

a special kind of child component that is rendered separately from the rest of thechildren The typical use of a facet is to provide special user interface sectionssuch as the footer for this panel There is more detail on facets in Chapter 6

The footer contains another UIPanel that has two submit buttons for thispage The code for the footer is copied here for reference

<f:facet name=”footer”>

<h:panelGrid id=”buttonGrid” columns=”2”

After the button is pressed and the action is invoked the returned “logicaloutcome” will be compared with the navigational rules specified in thefaces-config.xml file When the Save button is pressed, the navigationrules specify that the user be taken to the welcome.jsp page In this simpli-fied example, the welcome page simply displays the newly registered user’sname and says Welcome The code for that page is listed here:

<%@ taglib uri=”http://java.sun.com/jsf/html” prefix=”h” %>

<%@ taglib uri=”http://java.sun.com/jsf/core” prefix=”f” %>

</head>

<BODY>

<f:view>

<h:outputMessage value=”Welcome {0} {1}, to the Registration Demo!”>

In this chapter, we have looked at the details of how JSF integration workswith JSPs You saw that even though a JSP is using the JSF integration tags,there is nothing special about what is happening; it’s just normal JSP process-ing that takes place to invoke JSF API We also covered a sample page in detail

so that you could see the integration in action In the next chapter, you will seemore detail on UIComponent

The notion of UI components is one of the main axes around which theJavaServer Faces framework pivots The specification defines a User InterfaceComponent Model, in which classes that extend the UIComponent class—generically referred to as components—are the centerpiece But there is muchmore to the Component Model than just this class hierarchy

The UIComponent class sits at the nexus of a broad and diverse set of laborating classes These come in several varieties There are the taglibclasses—subclasses of UIComponentTag—that provide a mechanism wherebyJSP developers can gain access to the power of components There are thehelpers—Converter, Renderer, Validator—to which components often dele-gate some of their functionality Then, there are listeners and the events thatdrive them, plugging components firmly into the bedrock of the framework’s(and each application’s) dynamic behavior And finally there are the modelobjects with which components perform an intricate dance, as they coordinatetheir state with the state of the user interface

col-Beyond that, components form a buffer between a server-based Web cation and its clients, mediating between them to handle differences in datarepresentation (formatted strings for the client, Java types for the application’smodel), providing a focal point for basic services such as type conversion, for-matting, validation, and error messaging, while buffering input values for pre-sentation back to the user in the event of a conversion or validation error

appli-UI Components

C H A P T E R

6

In this chapter, we’ll explore these many aspects of components and gain anunderstanding of their framework collaborations, rooting our knowledge inconcrete examples of usage We’ll walk step by step through the User InterfaceComponent Model, examining each of its salient features in turn

We’ll begin by taking a guided tour through a JSP containing some basicFaces tags, exploring how JavaServer Faces implements their behavior behindthe scenes—including how the framework builds a tree of components to rep-resent the page’s elements Next, we’ll examine the role of components inbinding values from model objects to the user interface using concrete exam-ples to further our understanding

As we work our way through the chapter, we’ll progressively build anexample application, gradually incorporating more complex components,including panel, facets, and select lists We’ll learn how to configure type con-version, validation, and error messaging in the sample application as well, atthe same time examining the underlying implementation of each feature.We’ll also learn how to use actions and listeners to provide dynamic behav-ior Toward the end of the chapter, you’ll see an example of a listener thatmanipulates the view dynamically, modifying the user interface in response touser actions

Overview

Learning about JavaServer Faces components requires covering a broad range

of topics First, of course, there is the UIComponentBase class itself, anabstract subclass of the UIComponent class, which we will gradually unfoldthroughout the chapter At the beginning and again at the end of eachrequest/response cycle, the JSF framework either builds or retrieves an object

graph—referred to as the view—of UIComponents and their dependents

Col-lectively, these objects represent the state of a Web page and the renderinglogic required to generate it

The view can be configured in JSP or built dynamically in Java code, thoughmany applications will likely do some of both—defining most of the userinterface in JSP, but at times manipulating it by adding, removing, or modify-ing components programmatically

Components play a central role in binding values from the user interfacedirectly to model objects, providing with the aid of helpers, all the necessaryparsing, type coercion, formatting, and validation behavior Developers can

use JSP or Java code to configure a Converter (a Converter converts the stringvalues found in the browser to the values expected by the components such asIntegers etc.) as well as one or more Validators (a Validator ensures that a valuemeets some defined criteria, such as a certain length, before allowing it to bepassed on to the component) on any given component This configurationcapability provides a handy set of extension points, allowing developers toprovide custom versions of these helper classes whenever and wherever nec-essary—even allowing developers to change them dynamically.

JavaServer Faces implements a sophisticated event model that closely rors the JavaBean event model, as well as a navigation scheme that incorpo-rates the Command Pattern Components are deeply involved here as well,queuing and receiving events Developers can register one or more listeners on

mir-a component vimir-a JSP or Jmir-avmir-a, mir-allowing the listeners to respond to events mir-ciated with the component

asso-Components also collaborate with configurable Renderers to generate theirown UI representation Because components have direct access to modelobjects, they participate both in formatting model values into their appropriate

UI string representations, and in rendering the HTML elements used topresent the values

Throughout the chapter, we will describe the various tags defined by the JSFspecification, presenting examples of their usage to drive home the conceptsand terminology We’ll describe how tags are used to pair components withspecific Renderers, allowing several components to share a single renderingbehavior, while also allowing a single component to have several different ren-dering behaviors

Using Components

Because the UI Component Model is fairly complex and its workings are tral to nearly everything the framework does, we will focus in this section onwhat is going on behind the scenes as we look at examples that illustrate itsusage We’ll begin by analyzing how the framework would process a simpleJSP, using the JSP responsible for rendering the Modify Invoice page depicted

cen-in Figure 6.1 as a startcen-ing pocen-int

Let’s assume that the form fields in the Modify Invoice page are bound to asimple invoice bean (Listing 6.1), which represents model values for an invoice

in a billing system

Figure 6.1 The Modify Invoice page.

private Date invoiceDate = new Date();

private BigDecimal amount = new BigDecimal(“1234.56”);

public InvoiceBean() { }

public String save() { // Code to perform save and setup for next page would go here // For now just return null to rerender the current page return null;

}

/* - Accessor methods -*/

Listing 6.1 A simple invoice bean.

public Integer getInvoiceNumber() { return invoiceNumber;

} public void setInvoiceNumber(Integer number) { this.invoiceNumber = number;

}

public Date getInvoiceDate() { return invoiceDate;

} public void setInvoiceDate(Date invoiceDate) { this.invoiceDate = invoiceDate;

}

public BigDecimal getAmount() { return amount;

} public void setAmount(BigDecimal amount) { this.amount = amount;

} }

Listing 6.1 (continued)

Apart from the save() method, InvoiceBean is a simple bean that can beused as a data container for invoice values The extra method is needed inorder to enable the Save button in the sample page

ACTIONS AND NAVIGATION

You may have noticed that the InvoiceBean class in Listing 6.1 contains a simple action method, save(), that takes no arguments and returns a string.

Although a good portion of Chapter 7, “Navigation, Actions, and Listenters,” is devoted to actions, we provide a brief introduction here because it should prove helpful to our understanding of components

Actions represent responses to UI controls such as buttons and hyperlinks.

Action methods are invoked reflectively, and must conform to a simple convention: they must take no arguments, return String, and have public visibility.

Action methods are bound to UICommand components via the action attribute of the command_button and command_link tags Because no arguments are passed to action methods, they must rely on other properties of the bean to provide whatever context they need to carry out their tasks For example, an action method triggered by clicking a Save button might be responsible for transfering the bean’s values to a persistence service in the business tier.

The values of the InvoiceBean in Listing 6.1 are bound to componentsconfigured by Faces tags in ModifyInvoice.jsp (see Listing 6.2) In the nextfew pages, we’ll walk through the main elements of the JSP, in the process get-ting a quick overview of components and their associated tags

<html>

<head>

<meta http-equiv=”Content-Type”

content=”text/html; charset=iso-8859-1”>

<link rel=”stylesheet” href=”/ch6ex1/styles.css” type=”text/css”>

<title>Chapter 6, Example 1</title>

<%@ taglib uri=”http://java.sun.com/jsf/html” prefix=”h” %>

<%@ taglib uri=”http://java.sun.com/jsf/core” prefix=”f” %>

The first thing you will notice right at the top of ModifyInvoice.jsp isthe pair of scriptlet statements that import the Faces taglibs Note that the pre-

fixes, which are recommended by the Faces specification, are h: for the Faces HTML taglib, and f: for the Faces Core taglib

<%@ taglib uri=”http://java.sun.com/jsf/html” prefix=”h” %>

<%@ taglib uri=”http://java.sun.com/jsf/core” prefix=”f” %>

If you take a quick scan of the JSP code, you’ll notice that most of the tags arepreceded by ‘h:’, the exception being the f:view tag that encloses the Faces

portion of the JSP This denotes the root of the view, which is represented at run

time by an instance of UIViewRoot UIViewRoot is a subclass of nentBasethat implements methods for broadcasting events to the other com-ponents in the tree

UICompo-The next thing you’ll likely notice is an id attribute that uniquely identifieseach of the Faces HTML components You can use the value of this attribute tolocate a given component on the server at run time JSF allows you to modifyand even add or remove components dynamically You can also easily addressthe elements with JavaScript This a powerful and quite useful feature Before the beginning of the HTML table, you’ll see a Faces form tag, which

is responsible for rendering a corresponding HTML form tag Just above that

is a graphicImage tag, which is used to render an HTML img tag, and anoutputLinktag, which renders an anchor

There are several outputText tags that—in the current example—donothing more than render the hard-coded strings specified by their valueattributes Obviously, the strings could have been directly in the JSP withoutthe use of Faces tags, but given that the framework allows dynamic manipula-tion of components on the server, there can be advantages to the approachused here In addition, the outputText tag provides a styleClassattribute, which allows us to assign a CSS class to be used to style the string

As a result, the string will be rendered inside an HTML span tag bound to thespecified CSS class

The input_text tags in ModifyInvoice.jsp are used to render HTMLtext input elements The tags’ value attributes bind each input field to a cor-responding InvoiceBean property The framework supplies default conver-sion facilities that allow the field values to be coerced to Numbers, Dates, andother common Java types as necessary

Finally, near the end of the sample code there is a command_button that isused to render an HTML submit button Listing 6.3 displays the HTML thatresults when JavaServer Faces renders ModifyInvoice.jsp Note how theframework automatically combines the form ID with the field ID to generateunique identifiers for the name attributes of the HTML input tags, for examplename=”invoice:invoiceNumber”for the Invoice Number field:

<head>

<meta http-equiv=”Content-Type”

content=”text/html; charset=iso-8859-1”>

<link rel=”stylesheet” href=”/ch6ex1/styles.css” type=”text/css”>

<title>Chapter 6 Example 1</title>

When the Faces implementation renders the response, the view is then erenced to determine how to render the components When a user submits theform contained in the Modify Invoice page back to the server, the view is usedagain, playing an integral role in every step of the framework’s request-processing functionality

ref-Figure 6.2 The UIComponentBase class.

The UIComponentBase class defines a children property of type List toallow instances to be assembled into a tree (see Figure 6.2) Let’s take a look atthe view that the framework would generate to represent the Faces tags inModifyInvoice.jsp Figure 6.3 provides a conceptual diagram

Figure 6.3 The Component tree for the Modify Invoice page.

use_faces

Tags in JSP

graphic_image output_text form output_link

output_text input_text command_button

UIViewRoot

Component Tree in FacesContext

HtmlGraphicImage HtmlOutputText HtmlForm HtmlCommandLink

HtmlInputText HtmlOutputText HtmlCommandButton

contains

- children: List

0 *

UIComponentBase

During the Render Response phase, the framework gives each component in

the tree an opportunity to render itself, and appends the resulting HTMLstring to the response The abstract UIComponent class declares the followingset of encoding methods for this purpose:

public abstract void encodeBegin(FacesContext facescontext) throws IOException;

public abstract void encodeChildren(FacesContext facescontext throws IOException;

public abstract void encodeEnd(FacesContext facescontext) throws IOException;

Components may delegate some or all of their rendering behavior to a derer instance JSF encourages this approach, but doesn’t enforce it To providethis flexibility, the Renderer abstract base class provides default implementa-tions of a set of encoding methods that are parallel to those of UIComponent

Ren-public void encodeBegin(FacesContext facescontext, UIComponent uicomponent) throws IOException { } public void encodeChildren(FacesContext facescontext, UIComponent uicomponent) throws IOException { } public void encodeEnd(FacesContext facescontext, UIComponent uicomponent) throws IOException { } Public Boolean getRenderersChildren()

Renderers are simple helper classes whose purpose is to allow common dering functionality to be abstracted out of components This allows for reuse,

ren-in that different components can share the same Renderer More importantly,making Renderers pluggable allows a single component to have multiplevisual representations As you can see from Figure 6.3, the UICommand com-ponent can be rendered either as a hyperlink or as a button

In general, Faces tags are designed to pair a component with a specific derer However, there are a handful of components that either require no ren-dering at all—for example the view tag we encountered earlier—or that do all

Ren-of their own rendering instead Ren-of delegating to a Renderer (Note that some Ren-ofthese details may vary among different JSF implementations.)

Subviews

JSF pages are only allowed to contain a single view tag However, the Facestag library provides a subview tag that can be used to nest content from a sep-arate JSP inside a view tag This provides a convenient way for your pages toshare common snippets of JSF markup

For example, the Modify Invoice page’s header is rendered by the followingtable (as seen in Listing 6.2):

<head>

<link rel=”stylesheet” href=”/ch6ex2/styles.css” type=”text/css”>

<%@ taglib uri=”http://java.sun.com/jsf/html” prefix=”h” %>

<%@ taglib uri=”http://java.sun.com/jsf/core” prefix=”f” %>

<f:subview id=”header”/>

<jsp:include page=”Header.jsp” flush=”true”>

<jsp:param name=”pageName” value=”Modify Invoice”/>

Here is the code for the Header.jsp:

<html>

<head>

<link rel=”stylesheet” href=”/ch6ex2/styles.css” type=”text/css”>

<%@ taglib uri=”http://java.sun.com/jsf/html” prefix=”h” %>

<%@ taglib uri=”http://java.sun.com/jsf/core” prefix=”f” %>

repre-of any conversion applied to the submitted value during the Apply Request

Val-ues phase Ultimately, the content of the component’s value field is transferred

to the corresponding bean property during the Update Model Values phase.

JSF provides a value binding mechanism to make it easy to access beanproperties from within Faces tags The entry point to this mechanism is the

value attribute used by the inputText and ouput_text tags we saw inListing 6.2:

<h:input_text id=”amount”

value=”#{invoiceBean.amount}”>

Expressions that begin with a ‘#{‘ and are terminated with a trailing ‘}’are evaluated by the framework’s value binding mechanism This mechanismprovides a bidirectional facility for mapping values between UIComponentsand the model bean properties to which they are bound In fact, the whole JSP2.0 Expression Language (EL) is honored, so you can do things like

#{myBean.value < 16}

In the previous example, the expression #{invoiceBean.amount} would

be resolved at run time by evaluating each dot-separated substring (minus theopening ‘#{‘ and the trailing ‘}’) in turn from right to left (We’ll refer to the

substrings as keys, and the entire string as a keypath.) The first key is always

assumed to be an object in one of the scopes accessible to the JSP—session,request, or application Successive keys are assumed to reference properties ofthe object represented by the preceding key

In the previous example, the value binding mechanism would resolve thekeypath invoiceBean.amount by using reflection to access the amountproperty of invoiceBean If a property matching the key ‘amount’ couldnot be found on invoiceBean, the associated component’s value would beset to null

The value binding mechanism can be applied to nested, indexed, andmapped properties Let’s look at a couple of examples First, we’ll add a newvalue object to our model AccountBean contains values that span multipleinvoices—for example, the company name—as well as a list of invoices thatbelong to the account it represents To make things more interesting, we’ll cre-ate a reciprocal relationship between AccountBean and InvoiceBean, asdepicted in Figure 6.4

Listing 6.4 contains the code for the AccountBean class

Figure 6.4 AccountBean/InvoiceBean relationship.

private String companyName;

private List invoices = new ArrayList();

public AccountBean() { // Construct with predefined values for now setCompanyName(“Some Company, Inc.”);

}

public List getInvoices() { return invoices;

} public void setInvoices(List invoices) {

Listing 6.4 AccountBean.java (continued)

this.invoices = invoices;

} }

Listing 6.4 (continued)

We’ll need to make some subtle changes to the InvoiceBean class as well

In particular, we’ll add an account property, as well as an extra convenienceconstructor, as shown in Listing 6.6

We’ll also add a JavaBean to represent the Modify Invoice page This willgive us a place to put page-related state, as well as behavior (in the form ofaction methods) For example, we can move the save() method from the ear-lier version of InvoiceBean (Listing 6.1) to our new class, ModifyIn-voicePage, depicted in Listing 6.5

/** The value object managed by this page */

private InvoiceBean invoice;

/** Field labels for the user interface */

private static Map labels = new HashMap();

static { labels.put(“invoiceNumber”, “Invoice No.”);

labels.put(“invoiceDate”, “Invoice Date”);

labels.put(“amount”, “Amount”);

}

public ModifyInvoicePage() { // Construct with predefined values for now InvoiceBean anInvoice = (InvoiceBean)

Listing 6.5 ModifyInvoicePage.java.

/* - Accessor methods -*/

public Map getLabels() { return labels; }

public InvoiceBean getInvoice() { return invoice;

} public void setInvoice(InvoiceBean invoice) { this.invoice = invoice;

} }

Listing 6.5 (continued)

Listing 6.6 is a new version of InvoiceBean that implements the ship with AccountBean The SaveAction no longer appears here because it isnow in the ModifyInvoicePage

private Integer invoiceNumber;

private Date invoiceDate;

private BigDecimal amount;

private AccountBean account;