Mastering JavaServer™ Face phần 6 ppt

We’ll learn how to code action methods that provide the required application logic, as well as how to configure navigation rules in the applica- tion configuration file by default, faces

public InvoiceBean() {

paymentTerms.add(new SelectItem(“0”, “On Receipt”, “”));

paymentTerms.add(new SelectItem(“30”, “Net 30 Days”, “”));

paymentTerms.add(new SelectItem(“60”, “Net 60 days”, “”));

}

public List getPaymentTerms() { return paymentTerms; }public void setPaymentTerms(List paymentTerms) {this.paymentTerms = paymentTerms;

}

public String getPaymentTerm() { return paymentTerm; }public void setPaymentTerm(String paymentTerm) {this.paymentTerm = paymentTerm;

}

Now we can add tags to ModifyInvoice.jsp (see Listing 6.12) to render

a drop-down menu based on the list of SelectItems stored in the Terms property:

Similarly, we could follow the same set of steps used in the previous ple to add a set of radio buttons First, here’s the new code we need to add to the InvoiceBean class:

exam-

/* List of possible order status codes */

private List statusCodes = new ArrayList();

/* Current order status */

private String statusCode = “”;

public InvoiceBean() {

statusCodes.add(new SelectItem(“1”, “Open”, “”));

statusCodes.add(new SelectItem(“2”, “Past Due”, “”));

statusCodes.add(new SelectItem(“3”, “Paid”, “”));

}

public List getStatusCodes() { return statusCodes; }public void setStatusCodes(List statusCodes) {this.statusCodes = statusCodes;

}

public String getStatusCode() { return statusCode; }public void setStatusCode(String statusCode) {this.statusCode = statusCode;

}

Now we can add the JSP tags:

Check boxes are a bit different They are backed by the UISelectBoolean component, which binds its value to a single property of type boolean, rather than to a list of SelectItems To add check boxes to a page, we simply add boolean properties to the bean class, one per check box, and then add a tag for each check box in our JSP Here’s the additional Java code we would need

to add to the InvoiceBean to support a pair of check boxes:

}

public boolean isExpedited() { return expedited; }public void setExpedited(boolean expedited) {this.expedited = expedited;

}

We could then add the following to our JSP:

As we have seen, components play a central role in JavaServer Faces They laborate with tags and Renderers to generate the presentation, work with Con- verters to convert values between Java types and their UI representations, assist in validation along with any registered Validators, provide a registry for listeners, and implement the mechanisms needed to assemble and manage the view

In the previous chapter, “UI Components,” we learned about JSF’s rendering and value binding facilities From an MVC perspective, our focus was primar- ily on understanding how to implement the view portion of a JSF-based Web application Now let’s turn our attention to the controller tier.

JavaServer Faces provides facilities for binding UI controls to arbitrary methods on backing beans that can be used to define how an application responds to user-initiated events These action methods then collaborate with

a built-in navigation management system that allows developers to specify navigation rules declaratively in XML.

Under the covers, JSF uses an Event/Listener model, familiar to many UI developers, which allows developers to access and manipulate component state at any stage of the request/response cycle It also provides convenient extension points for customizing the framework’s behavior.

In combination, these facilities provide a straightforward foundation for building the controller layer of an MVC Model 2 Web application.

Overview

In this chapter, we will explore the framework’s navigation mechanism We’ll

do so by progressively developing an example application composed of eral related pages—modeled on a typical, real-world business application

sev-Navigation, Actions,

and Listeners

C H A P T E R

7

scenario We’ll learn how to code action methods that provide the required application logic, as well as how to configure navigation rules in the applica- tion configuration file (by default, faces-config.xml) to manage the appli- cation’s page flows

We’ll also learn about how and when to implement ActionListeners and ValueChangeListeners to handle some of the subtler issues that can arise when using JSF to develop nontrivial Web applications.

Actions and Navigation

Implementations of JSF must provide an implementation of the Action Listener interface to serve as a default listener at the application level When

the framework generates the component tree for a given page (during Restore View or Render Response), any components of type UICommand are registered

with this listener.

A component that implements the ActionSource interface (for example, UICommand) will queue an ActionEvent when the framework invokes its processDecodes() method At the end of the Invoke Application phase (or the Apply Request Values phase if the component’s immediate property is set

to true), the default ActionListener is responsible for dispatching these events by evaluating the component’s method binding expression to locate an action method that it can then invoke Action methods must take no argu- ments and return a string

The default ActionListener passes the string returned from the action method to the framework’s default NavigationHandler The Navigation Handler in turn looks for a matching navigation rule in the application con- figuration file If a matching value is found, the NavigationHandler calls setViewRoot() on the FacesContext with the name of the new view.

If no match is found, the current view (and its tree of components) remains

unchanged At the end of the Invoke Application phase (Apply Request Values if

immediate was set to true), the framework passes control to the Render Response phase, at which point the current view in the FacesContext is

rendered.

You can customize the framework’s behavior if desired by substituting your own implementations for the default ActionListener, the default NavigationHandler , or both if you wish, by calling setApplication Listener() or setNavigationHandler() on the application instance as necessary.

JSF provides several features that allow you to manage navigation between your application’s pages The simplest of these is to use an outputLink tag to render an HTML anchor tag that references a JSP page, as in the following example:

JSF implementations would typically render this in HTML as follows:

<a href=”Search.jsp” class=”Link”>Search by Account Number</a>

While this works for simple navigation, it doesn’t provide for the dynamic behavior that many of the pages in typical Web applications require For exam- ple, suppose that we were creating a simple search page similar to the one in Figure 7.1.

Figure 7.1 A simple search page.

The Search page picture in Figure 7.1 provides a single input field into which a user may enter an account number, and a button to submit the enclos- ing form When the form is submitted, there are actually two separate bits of dynamic behavior that the application should carry out One is the actual search, which in the example code we’ll be looking at shortly is delegated to a business tier service The other is deciding which page to navigate to based on the outcome of the search That is, if a matching account is found, we want to navigate to a page that displays the results Otherwise, we want to rerender the Search page with an error message indicating that no matching account was found.

To make implementing these types of scenarios as easy as possible, the UICommand component provides an action attribute that can be bound to an

arbitrary method on a backing bean via a method binding expression (a special

type of value binding expression), as follows:

title=”Search by account number”/>

<input type=”hidden” name=”searchForm” value=”searchForm” />

it is unique within the page.

If we wanted to use a hyperlink instead of a button to submit the form, we could simply replace the commandButton tag in the previous example with a commandLink tag as in the following code:

<input type=”hidden” name=”form:link”/>

<input type=”hidden” name=”form” value=”form” />

</form>

Note that the Renderer also adds another hidden form field, this time

to identify the control that submitted the form, since the HTML anchor tag doesn’t provide an id attribute.

Implementing Application Actions

Methods that are bound to a UICommand’s action attribute via a method

reference expression are referred to as application actions JSF uses reflection at

run time to locate and execute application actions, provided that they observe the following API convention: they must be public methods that take no para- meters and return String For example, here’s the signature that would be required for the search() method:

public String search()

When a button or hyperlink backed by a UICommand component is clicked, JSF will look for a method whose signature conforms to this guideline and attempt to invoke it dynamically To create a working example of a search() method, we would need to code a JavaBean exposing an application action method whose name corresponds to the final portion of the method binding expression For example, let’s take a look at the search() method in the SearchPage class in Listing 7.1.

* Searches for an AccountBean instance corresponding to the value

* of the <code>accountNumber</code> attribute If no match is

* found, adds an error message to the FacesContext and returns

* <code>null</code> Otherwise, returns “viewInvoices” after

* locating the ViewInvoicesPage and passing it the AccountBean’s

}catch (BusinessDelegate.NotFoundException e) {FacesContext context = FacesContext.getCurrentInstance();context.addMessage(null, MessageFactory

getMessage(“noMatch”, new Object[] { accountNumber }));return null;

Note that the search() method in Listing 7.1 returns either null, or the string ‘viewInvoices’ In general, the value returned by an application

action method is referred to as its outcome The outcome is mapped to a tion rule specified in the application configuration file To get our application

naviga-action working, we must configure a navigation rule to define a mapping for the viewInvoicesoutcome

Specifying Navigation Rules

Listing 7.2 is a simple navigation rule that binds the viewInvoice outcome

to the file ViewInvoices.jsp, which we will use to display the search results:

Listing 7.2 A simple navigation rule.

The from-tree-id element tells the framework that this rule applies only

to navigations that result from the evaluation of a method binding expression referenced by an ActionSource component in the Searchpage.jsp com- ponent tree In this example, that would be the reference to searchPage search in the commandLink tag in SearchPage.jsp:

by the associated to-tree-id element, in this case ViewInvoices.jsp.

Note that we can optionally code the outcome string directly in the JSP instead

of providing a method binding expression, as shown in the following code:

Listing 7.3 A global navigation rule for the Home page.

This navigation rule simply omits the from-tree-id element, allowing the rule to be accessed from any JSP These are just a few examples of the con- figuration options available for navigation rules For further details, please see Chapter 4, “JSF Configuration.”

Working with Forms

Listing 7.4 contains a complete source listing for the JSP that renders the Search page we described earlier (Listing 7.1).

<html>

<head>

<meta http-equiv=”Content-Type”

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

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

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

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

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

</head>

Listing 7.4 Search.jsp.

<f:view>

<f:subview id=”header”>

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

<jsp:param name=”pageName” value=”Search”/>

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

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

</head>

Listing 7.5 HTML generated by Search.jsp (continued)

<! HTML generated by heading subview omitted !>

<form id=”searchForm” method=”post”

the actual method referenced by the binding In this case that will be the SearchPage class’s search() method, as shown in Listing 7.6, which dele- gates the actual search to the findAccount() method of a helper class named BusinessDelegate.

private Integer accountNumber;

private transient BusinessDelegate delegate =BusinessDelegate.getDelegate();

public SearchPage() { }

/**

* Searches for an AccountBean instance corresponding to the value

* of the <code>accountNumber</code> attribute If no match is

* found, adds an error message to the FacesContext and returns

* <code>null</code> Otherwise, returns “viewInvoices” after

* locating the ViewInvoicesPage and passing it the AccountBean’s

}catch (BusinessDelegate.NotFoundException e) {FacesContext context = FacesContext.getCurrentInstance();

// Note: you could place the account values in the request// and let ViewInvoicesPage instances retrieve them as necessary// instead of setting them directly the way we do here.

ValueBinding binding =Util.getValueBinding(“#{viewInvoicesPage}”);

ViewInvoicesPage viewInvoicesPage = (ViewInvoicesPage)binding.getValue(FacesContext.getCurrentInstance());

viewInvoicesPage.setInvoices(account.getInvoices());

viewInvoicesPage.setAccountNumber(account.getAccountNumber());viewInvoicesPage.setCompanyName(account.getCompanyName());

}}

Listing 7.6 (continued)

Note that the actual implementation of the BusinessDelegate is portant to our example—the BusinessDelegate is simply a placeholder here for whatever functionality would be required to access the application’s persistence services.

unim-The BusinessDelegate’s findAccount() method throws a specific exception type if there is no match for the provided account number If that happens, the search() method catches the exception and adds an appropri- ate error message to the FacesContext, returning null to cause the current page to be rerendered Otherwise, it prepares the next page for rendering and returns viewInvoices.

Once the search() method exits, control returns to the default Action Listener’s processAction() method The ActionListener then invokes the handleNavigation() method on the application’s default NavigationHandler , passing it the application action’s outcome value The

NavigationHandler would then search for a navigation rule in the cation configuration file that matches the provided outcome (in this case viewInvoices ) Here’s an example of a matching navigation rule:

left unchanged In either case, the framework then passes control to the Render Response phase, at which point the component tree referenced by the view ID

will be rendered If the view ID hasn’t changed, the current component tree (representing the page that was just submitted) is rerendered.

In our example, we add an error message to the FacesContext and return null if no match was found This results in the Search page being regenerated with the new error message Otherwise, we return ‘viewInvoices’, which changes the view ID, causing the View Invoices page (ViewInvoices.jsp

in Listing 7.7, backed by ViewInvoicesPage.java in Listing 7.9) to be rendered.

However, before the new page can be rendered, we must arrange for the ViewInvoicesPage bean to receive the search results that are to be dis- played The search() method uses a ValueBinding to locate the object in the available scopes It then invokes one of the bean’s mutators to pass it the search results An alternative approach would be to place the results in the request or the session under a well-defined, globally unique key

Complex Forms

The View Invoices page presents two different scenarios where you might fer to use a hyperlink rather than a button to submit a form As you will see, JSF supports this transparently The file ViewInvoices.jsp shown in List- ing 7.7 contains a dataTable that renders an HTML table consisting of a header, a footer, and an arbitrary number of body rows (depending on the size

pre-of the list returned by a given search)

<head>

<meta http-equiv=”Content-Type”

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

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

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

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

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

</head>

<body>

<f:view>

<f:subview id=”header”/>

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

<jsp:param name=”pageName” value=”View Invoices”/>

<jsp:param name=”linkUrl” value=”Search.jsp”/>

<jsp:param name=”linkText” value=”Search Again”/>

title=”Delete selected invoices”

<f:facet name=”header”>

<h:commandLinkid=”invoiceNumber”

The dataTable tag’s var attribute defines a key that can be used to access the current bean during a given iteration of the Collection Nested tags can then use the key in value reference expressions to access individual properties

of the current bean Let’s take a closer look at a single column Here’s the code for the Invoice Date column:

<h:column>

<f:facet name=”header”>

<h:commandLinkid=”invoiceDateId”

/** Sort the invoice list on the invoiceDate property */

public String sortInvoiceDate() {Collections.sort(invoices,new InvoiceBean.InvoiceDateComparator());

return null;

}

Because we need the hyperlink to submit the form, the commandLink’s Renderer automatically inserts the necessary JavaScript For example, the HTML for the Invoice No anchor tag would look something like this:

Actually to get this to fit neatly on the page, we had to shorten the id ues: invoiceForm was shortened to form, table to tbl, and invoiceNum- ber to num This brings up an interesting point Since the values of the id attributes of UIComponents are rendered in the resulting HTML tags, it’s probably a good idea to keep the names short, though longer names can aid readability You might try using longer names at first when you are experi- menting with the framework, to make the HTML as readable as possible That’s often helpful for getting an initial understanding of what’s going on Also, note that JSF will autogenerate unique identifiers wherever you don’t supply your own Since these are provided mainly to aid in client-side script- ing, (though they can come in quite handy on the server side as well) these autogenerated IDs may not be to your taste, but then to each his own

val-Anyway, the idea behind the column header hyperlinks we have been ing at here is simply to allow a user to sort on the values of any given column

look-by clicking on the column’s heading, as shown in Figures 7.2 and 7.3.

Figure 7.2 The View Invoices page displaying a list of invoices.

For example, clicking the Amount column heading on the page shown in Figure 7.2 would switch the table from being sorted by invoice number to being sorted by amount The result would be the changed ordering shown in Figure 7.3 Of course this example is a bit simplistic, in that it only provides for sorting in ascending order; a bit more JSP code would be required to keep track of the sort direction for each column.

Figure 7.3 The View Invoices page after clicking the Amount hyperlink.

One other interesting point about this JSP is that the Invoice No column ues are also rendered as hyperlinks Here’s the JSP that renders the column:

val-<h:column>

<f:facet name=”header”>

<h:commandLinkid=”invoiceNumber”

HOW NAVIGATION WORKS BEHIND THE SCENES

When it builds the component tree for a given page, the framework automatically registers all the UICommand components with the application’s default ActionListener If the user activates one of these components (by clicking it in the user interface) the component adds an event to the event

queue During the Invoke Application phase, the framework handles the event

by invoking the listener’s processAction() method.

The ActionListener’s processAction() method has two possible means of determining the action’s outcome If the component’s action attribute is set with a simple string value, the literal value is used as the outcome If the attribute’s value is in the form of a method reference expression, the listener uses the value as a method binding and attempts to invoke the referenced method reflectively The outcome then is the invoked method’s return value.

This value is then passed to the NavigationHandler, which uses it to select the next component tree to render.