Beginning Apache Struts - From Novice To Professional (2006)

•Architecture: The emphasis of JSF is on architecture—how the various components talk among themselves, how requests are processed, and so forth. The emphasis is not on specific components (like a drop-down list, a tab view, or a validator for email addresses). In fact, JSF is specifically designed to be extended.

•Web-based UI components: An example might help. I use OpenOffice as my word processor. I’ve customized the toolbar so that it displays certain buttons every time I load OpenOffice. Some buttons are highlighted, like the Align button to indicate the currently active alignment. Also, when I click Save As, OpenOffice remembers the directory I last saved a file in and gives me a Save dialog box with that folder selected. Now imagine implementing all these features in your own webapp. Where would you start? The reality is that making a web-based application behave like an ordinary desktop app is very challenging. Web-based UI components and the request processing machinery behind them help you achieve this goal.

Unlike Struts, which usually gives you just one or two ways to accomplish a given task, the JSF specification is very flexible, and there are many combinations you can pick from to accomplish a task. This flexibility might create the false impression that JSF is too complex to work with.

In one sense this is true. JSF is complex, but most of the complexity is hidden from page developers and application developers who use it to build webapps. The complexity only becomes apparent when you’re extending JSF—for example, by creating new UI components, or providing integration points to other frameworks (e.g., the Commons Validator framework or Spring).

In short, it’s quite easy to use JSF to build webapps, but it’s more difficult to make significant extensions to it. And among the possible ways to extend JSF, it’s probably easiest to make extensions to the UI components and validators.

Shale Overview

Unlike JSF, which is a specification, Shale is actual software that you can use immediately. Shale is touted to be a complete reworking of Struts (which we’ll sometimes refer to as “classic” Struts for clarity). The reworking has been quite thorough, and it’s unlikely that

a Struts developer will recognize it as Struts!

Shale is based on JSF. By this, I mean JSF is to Shale what JSP is to Struts. There would be no Shale without JSF. You need an implementation of JSF (like MyFaces) in order for Shale to work. I don’t mean to belabor the point, but it is crucial that you understand this.

STRUTS TI AND STRUTS OVERDRIVE

Struts Shale isn’t the only “nouveau Struts” around—“Struts Ti” and “Struts OverDrive” are both under development.

Struts Ti (short for Titanium) is a merging of classic Struts and WebWork. WebWork is an open source web application framework, generally viewed as being technically sounder than Struts, yet similar enough to it for a merging to be possible. At the time of this writing, information on Struts OverDrive is scarce, but I’m guessing that it’s Struts using the Nexus framework for View/Controller communication. The Nexus framework handles text formatting, localization, and type conversions. This framework actually applies to many different webapp frameworks (Spring, Struts, etc.) and presentation layers (JSP, ASP.NET, etc.). OverDrive is the brand name given to applications that utilize the Nexus framework. Refer to “Useful Links” for details on both Ti and OverDrive.

As with Shale, these projects are quite different compared to Struts as you know it from this book. In my (admittedly cynical) view, they have a “Struts” prefix to tap into the large existing Struts user base. But I fear this is a mistake. Splitting a brand name only makes sense if there are distinct, clearly identifiable niches that each split addresses. Microsoft’s desktop/server offerings are a good example. Each addresses a clearly different niche under the “Windows” umbrella. But in the case of webapp frameworks, no clear multiplicity of niches is apparent, so having four frameworks called “Struts” simply creates confusion, actually diluting the Struts brand. I believe most CIOs would stick with the tried-and-tested classic Struts, or if they were intending to migrate, consider more mature frameworks like Spring or standards-based JSF. Very few would explore Struts X. In fact, it is more likely that they would have chosen the original WebWork instead of its morph with Struts (that is, Struts Ti). Now, they are likely to look at neither one.

In my opinion, it’s the project that remains backward compatible with Struts 1.x, while introducing major improvements over time, that will win the day—or rather, the users. At the time of this writing, that winning horse looks like Struts 1.x. This likelihood is increased if the Struts-Faces integration library (described later in this chapter) sees more development. Shale might come in a close second because of the superior features it offers.

Shale has three major design objectives:

•Expanding JSF past the View tier: Shale provides support for areas poorly addressed by the JSF specification (like the practicalities of validating user input). Recall that JSF is mainly about the View tier, so Shale has to do a fair bit to make JSF palatable to longtime Struts developers used to the comforts of the Validator framework, dynamic forms, and Tiles.

•A more complex request processing lifecycle: Because JSF uses server-side UI components, it processes incoming HTTP requests differently from Struts. JSF’s request processing lifecycle is divided into several phases. This is unlike Struts, which has just two phases: one for when the ActionForm gets validated and the other when the Action’s execute() function is called. Also, JSF allows your own classes to listen for events at the end of each phase (more on this in the following subsections). This is a huge improvement over Struts, and is what makes JSF so extensible.

•Some configuration information moved away from configuration files into JSPs: JSF has no notion of the Validation framework, dynamic forms, or Tiles, so config files for these do not exist. Instead, validations, for example (and as you will see, many other things), are specified in JSPs that make up the webapp. Like Struts, JSF does have a config file, called faces-config.xml, so not all the configuration information goes out to JSPs.

It is important to take note of these two points to help lessen the cognitive dissonance you (as a Struts developer) might experience when learning JSF.

Server-Side UI Components

When a page is submitted to a Struts webapp, the form data on the page is stored in an ActionForm subclass. Normally, we’d think of the ActionForm as a temporary storage area for data destined for the Model tier.

While perfectly true, another way of looking at the ActionForm is to say that it stores the state of the View tier on the server. This state information can be used to redisplay the page if necessary (e.g., when you have simple validation errors) in its original condition.

For example, in the Registration webapp (see Chapter 5), when the user keys in an incorrect password, the page is redisplayed with the user ID that was originally keyed in.

With our new way of seeing things, we’d say that the data saved on the ActionForm was used to put the state of the View (the original user ID redisplayed) back into its original state.

JSF takes this way of seeing things to the extreme. JSF has tags for various UI components just like Struts has, with its <html:xxx> and <bean:xxx> tags. The big difference is that each JSF tag causes an object to be created on the server. This object is used to hold the UI component’s state. We’ll elaborate on this shortly.

One other thing that JSF takes to the extreme is the organization of the JSF tags. In Struts, we’re accustomed to a simple two-level nested hierarchy: an <html:form> can contain elements like an <html:input> or <html:submit>, as in this snippet:

<html:form action="MyHandler.do"> <bean:message key="myapp.prompt.name"/></td> <html:text property="name" size="60" /> <html:errors property="name"/>

<html:submit>

<bean:message key="myapp.prompt.submit"/> </html:submit>

</html:form>

This is a reflection of the fact that Struts display tags closely mirror ordinary HTML tags. The hierarchy for JSF, on the other hand, is much richer and you typically have more levels, as shown in Listing 20-1.

Listing 20-1. A Snippet of JSF Tags Showing a Hierarchical Organization

<f:view>

<h:panelGroup>

<h:messages style="color:red" globalOnly="true"/> <h:outputText value="#{reg_messages['title_reg']}" /> <h:form binding="#{user.container}">

<h:outputText value="#{reg_messages['user_id']}"/> <h:inputText id="userId"

value="#{user.userId}" required="true"> <x:validateRegExpr pattern='^[A-Za-z0-9]{5,10}$' />

</h:inputText>

<h:message for="userId" />

...

This hierarchical organization (the hierarchy is defined through nesting) allows you to finely control how the page is rendered for display to the user. You’ll see why later in this chapter.

For now, the important thing to note is that the corresponding server-side objects created by the page in Listing 20-1 are also nested in a tree-like fashion, as shown in Figure 20-1.

The first time a JSF page is requested, the tree of objects—let’s call it the “UI tree”—is created on the server. JSF uses the UI tree to create the HTML for the requested page.

The next time the same page is requested (by the same user, in the same session), this UI tree is re-created on the server, and is populated with data from the page. This data does not have to be only user input destined for the Model tier but can also include the states of each UI component.

For example, suppose a JSF page contains a tag for a treeview UI component, as you might have used in Microsoft Explorer or Outlook. A user requesting the page sees the treeview and clicks a node on it. The treeview expands, and the user clicks further, exposing more of the tree, as in Figure 20-2.

Figure 20-1. Corresponding UI tree on the server

Figure 20-2. A treeview in MyFaces

When the page is submitted, the state of the treeview—in other words, which nodes were expanded by the user—would be sent unobtrusively along with other data on the form. This data is stored on the server-side object representing the treeview component.

To summarize, unlike Struts, where a page’s data goes into a single ActionForm, in JSF a server-side UI tree is created to hold data—both the data destined for the Model tier and the data representing the state of the View. JSF makes no distinction between the two.

There are six phases in all (the solid boxes in Figure 20-3), and each phase and the events associated with it are completely processed before the subsequent phase is started.

■Note Events and event listeners are the mechanism by which JSF exposes its internals to third-party classes. They are an important extension point of JSF. We’ll describe both of these in the following section.

In Figure 20-3, we’ve marked two ways (validation errors and conversion errors) by which processing gets fast-tracked to the Render Response phase. In truth, event listeners that process events immediately after any phase may cause JSF to move into the Render Response phase.

FACES REQUESTS

Not all HTTP requests sent to the server are processed according to Figure 20-3, but only those requesting a JSF page. Such requests are termed faces requests. This is analogous to the way not every HTTP request is processed by Struts, but only those with the .do extension (by default). The corresponding extension for JSF is .jsf. (Again, this depends on how you’ve configured web.xml. Another common choice for a JSF extension is .faces.)

Your pages need not have the extension .jsf, but the call to them must. For example, suppose you have a JSP page containing JSF markup named mypage.jsp. To correctly call this page, you’d have to make a request for

http://www.mycompany.com/mypage.jsf

If you were to make a request for http://www.mycompany.com/mypage.jsp directly, you’d get an error message.

You can name your pages with a .jsf extension, but this would not work with a JSP 1.2–compliant servlet container. JSP 1.2 requires JSP pages to have the .jsp extension. So, the most portable method is to name your JSF pages .jsp and request them as .jsf.

Let’s look at each phase in detail. Don’t worry if some of my comments seem cryptic at the moment. I’ll explain the cryptic bits in the following subsections.

•Restore View: If this is the first time the user requests this page, then the UI tree (see the discussion in the previous subsection) is created. If this is the second time the page is created, then the UI tree is re-created with the previously saved state. Value bindings for each UI component are also processed at this phase.

•Apply Request Values: Each UI component on the UI tree is given a chance to update its state based on the information contained in the incoming HTTP request.

•Process Validations: In this phase, validations are processed. If there are errors, then processing is taken directly to the Render Response phase.

•Update Model Values: As its name implies, in this phase the Model tier is updated with the data from the UI tree. JSF knows which UI components hold data destined for the Model tier because you’ve specified this in the JSF markup. Data conversion errors will cause processing to proceed directly to the Render Response phase.

•Invoke Application: Navigation is performed based on action events posted during previous phases. It is also possible for your customizations of JSF to add other processing code to this phase.

•Render Response: The HTML output is created, based on either the navigation results or the existing UI tree (if the page is to be redisplayed). The state of the UI tree is also saved for processing on subsequent requests.

After every phase (except for Restore View and Render Response), events that might have been generated during that phase are processed.

Events are Java objects that contain information indicating a certain processing state. Events are generated by UI components on the UI tree, or by your own processing code attached to any phase. Processing of events is done either by JSF itself or by event listeners.

We’ll see how this is done next.

Events and Event Listeners

In this book, you’ve come across two design patterns: the MVC design pattern and the Singleton design pattern (in Chapter 19). Events and event listeners fall under a simple but powerful design pattern called Observer.

In the Observer design pattern, there are two roles. The first is that of a Publisher, a data source that gets updated from time to time. The second role is that of Subscriber, denoting entities interested in being updated with the latest data available on the Publisher.

A bad way to get Subscribers updated with the latest data is for them to interrogate the Publisher at regular intervals. This technique, called polling, is obviously inefficient: poll too fast and you waste CPU time; poll too slowly and you risk getting the data too late or losing it altogether.

Instead of polling, the Observer design pattern employs the “don’t call us, we’ll call you” maxim. Subscribers interested in getting data from the Publisher first register with the Publisher. When the new data arrives, the Publisher informs all its registered Subscribers.

Let’s take a concrete example. GUI frameworks like Swing or Abstract Windowing Toolkit (AWT) have classes representing visually displayed UI components, like buttons, check boxes, and so forth. Each of these GUI components needs to signal certain user interactions, like a mouse click over a button, or a key pressed in a text input box. Each such activity is called an event.

An event is usually represented by a Java class, which has fields containing data describing the event. For example, in the case of mouse clicks, a MouseClickEvent might contain the X and Y coordinates of the mouse click, as shown in Listing 20-2.

Listing 20-2. A Class to Represent Mouse Clicks

public class MouseClickEvent{

private int _x, _y;

public MouseClickEvent(int x, int y){ _x = x; _y = y;

}

public int getX(){ return _x; }

public int getY(){ return _y; }

}

Notice that classes representing events are usually immutable, meaning that you can only read data from them once they are created. The reason for this is because an event could be shared among many Subscribers. You don’t want any Subscriber to amend the event.

So we now have a class to represent mouse clicks. Great! But how to guarantee that Subscribers can actually understand the data contained in this event? Simple—have them implement a standard interface, shown in Listing 20-3.

Listing 20-3. The MouseClickListener Interface

public interface MouseClickListener{

public mouseClicked(MouseClickEvent mce);

}

So, a Subscriber implementing MouseClickListener explicitly declares that it understands how to process mouse clicks. Listing 20-4 shows an example of a Subscriber implementing

MouseClickListener.