Previous Section  < Day Day Up >  Next Section

2.4 Developing the User Interface Pages

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" %>

<html>

  <head>

    <title>Newsletter Subscription</title>

  </head>

  <body>

    <f:view>

      <h:form>

        <table>

          <tr>

            <td>Email Address:</td>

            <td>

              <h:inputText value="#{subscr.emailAddr}" />

            </td>

          </tr>

          <td>

            <td>News Letters:</td>

            <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:selectManyCheckbox>

            </td>

          </tr>

        </table>

        <h:commandButton value="Save"

          action="#{subscrHandler.saveSubscriber}" />

      </h:form>

    </f:view>

  </body>

</html>

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 prefix f (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. The value attribute contains a value binding expression that binds the component to the emailAddr property of an application bean named subscr. As you may recall, this is the name assigned to the Subscriber bean 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> element value attribute is set to a value expression that binds the component to the subscriptionIds property of the Subscriber bean available through the subscr variable.

Finally, there's an <h:commandButton> element representing the Save button, with an action attribute containing a method binding expression that binds it to the saveSubscriber() method of the SubscriberHandler bean available through the subscrHandler variable.

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
figs/Jsf_0203.gif

When the <h:textInput> element is processed, the corresponding UIInput component 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.

    Previous Section  < Day Day Up >  Next Section