JavaServer Faces Version of Coffee Break Server
JavaServer Faces is designed to provide a clean separation of the presentation layer and the model layer so that you can readily add JavaServer Faces functionality to existing applications. In fact almost all of the original Coffee Break Server back-end code remains the same in the JavaServer Faces technology version of the server.
This section provides some details on how the JavaServer Faces version of the Coffee Break server is different from the non-GUI framework version. Like the non-GUI framework version of the Coffee Break server implementation, the JavaServer Faces Coffee Break server is organized along the Model-View-Controller design pattern. Instead of the
Dispatcherservlet examining the request URL, creating and initializing model JavaBeans components, and dispatching requests to view JSP pages, now theFacesServlet(included with the JavaServer Faces API), performs these tasks. As a result, theDispatcherservlet has been removed from the JavaServer Faces version of the Coffee Break server. Some of the code from theDispatcherhas been moved to beans. This will be explained later in this section.As with the non-GUI framework version of the Coffee Break server, the JavaServer Faces Coffee Break server includes JavaBeans components that contain the business logic for the application: they call the web services and perform computations on the data returned from the services. The JSP pages format the data stored in the JavaBeans components. The mapping between JavaBeans components and pages is summarized in Table 35-2.
JSP Pages
orderForm
As in the non-GUI framework version of the Coffee Break server, the
orderFormdisplays the current contents of the shopping cart. The first time the page is requested, the quantities of all the coffees are 0. Each time the customer changes the coffee amounts and clicks the Update button, the request is posted back toorderForm.The
CoffeeBreakBeanbean component updates the values in the shopping cart, which are then redisplayed byorderForm. When the order is complete, the customer proceeds to thecheckoutFormpage by clicking the Checkout button.The table of coffees displayed on the
orderFormis rendered using one of the JavaServer Faces component tags,dataTable. Here is part of thedataTabletag fromorderForm:<h:dataTable id="table" columnClasses="list-column-center,list-column-right, list-column-center, list-column-right" headerClass="list-header" rowClasses="list-row" footerClass="list-column-right" styleClass="list-background-grid" value="#{CoffeeBreakBean.cart.items}" var="sci"> <f:facet name="header"> <h:outputText value="#{CBMessages.OrderForm}"/> </f:facet> <h:column> <f:facet name="header"> <h:outputText value="Coffee"/> </f:facet> <h:outputText id="coffeeName" value="#{sci.item.coffeeName}"/> </h:column> ... </h:dataTable>When this tag is processed, a
UIDatacomponent and aTablerenderer are created on the server side. TheUIDatacomponent supports a data binding to a collection of data objects. TheTablerenderer takes care of generating the HTML markup. TheUIDatacomponent iterates through the list of coffees, and theTablerenderer renders each row in the table.This example is a classic use case for a
UIDatacomponent because the number of coffees might not be known to the application developer or the page author at the time the application is developed. Also, theUIDatacomponent can dynamically adjust the number of rows in the table to accommodate the underlying data.For more information on
UIData, please see The UIData Component.checkoutForm
checkoutFormis used to collect delivery and billing information for the customer. When the Submit button is clicked, anActionEventis generated. This event is first handled by thesubmitmethod of thecheckoutFormBean. This method acts as a listener for the event because the tag corresponding to the submit button references thesubmitmethod with itsactionattribute:The
submitmethod submits the suborders to each supplier and stores the result in the request-scopedOrderConfirmationsbean.The
checkoutFormpage has standard validators on several components and a custom validator on the email component. Here is the tag corresponding to thefirstNamecomponent, which holds the customer's first name:<h:inputText id="firstName" value="#{checkoutFormBean.firstName}" size="15" maxlength="20" required="true"/>With the
requiredattribute set totrue, the JavaServer Faces implementation will check whether the user entered something in the First Name field.The
<h:inputText id="email" value="#{checkoutFormBean.email}" size="25" maxlength="125" validator="#{checkoutFormBean.validateEmail}"/>The
validatorattribute refers to thevalidateEmailmethod on theCheckoutFormBeanclass. This method ensures that the value the user enters in the email field contains an @ character.If the validation does not succeed, the
checkoutFormis re-rendered, with error notifications in each invalid field. If the validation succeeds,checkoutFormBeansubmits suborders to each supplier and stores the result in the request-scopedOrderConfirmationsJavaBeans component and control is passed to thecheckoutAckpage.checkoutAck
checkoutAcksimply displays the contents of theOrderConfirmationsJavaBeans component, which is a list of the suborders constituting an order and the ship dates of each suborder. This page also uses aUIDatacomponent. Again, the number of coffees the customer ordered is not known before runtime. TheUIDatacomponent dynamically adds rows to accommodate the order.JavaBeans Components
The JavaBeans components in the JavaServer Faces version of the Coffee Break server are almost the same as those in the original version. This section highlights what has changed and describes the new components.
CheckoutFormBean
The
validatemethod of the original version of theCheckoutFormBeanchecks the completeness of information entered intocheckoutForm. Because JavaServer Faces technology automatically validates certain kinds of data when the appropriate validator is registered on a component, thevalidatemethod ofcheckoutFormBeanis not necessary in the JavaServer Faces version of that bean.Several of the tags on the
checkoutFormpage have theirrequiredattributes set totrue.This will cause the implementation to check whether the user enters values in these fields. The tag corresponding to thevalidateEmailmethod:public void validateEmail(FacesContext context, UIComponent toValidate, Object value) { String message = ""; String email = (String) value; if (email.indexOf('@') == -1) { ((UIInput)toValidate).setValid(false); message = CoffeeBreakBean.loadErrorMessage(context, CoffeeBreakBean.CB_RESOURCE_BUNDLE_NAME, "EMailError"); context.addMessage(toValidate.getClientId(context), new FacesMessage(message)); } }As in the non-GUI framework version of the Coffee Break server, if the information is incomplete or invalid, the page is rerendered to display the error messages. If the information is complete, order requests are constructed from the shopping cart and the information supplied to
checkoutFormand are sent to each supplier.CoffeeBreakBean
CoffeeBreakBeanis exclusive to the JavaServer Faces technology version of the Coffee Break server. It acts as the backing bean to the JSP pages. See Backing Bean Management for more information on backing beans.CoffeeBreakBeancreates theShoppingCartobject, which defines the model data for the components on theorderFormpage that hold the data about each coffee.CoffeeBreakBeanalso loads theRetailPriceListobject. In addition, it provides the methods that are invoked when the buttons on theorderFormandcheckoutAckare clicked. For example, thecheckoutmethod is invoked when the Checkout button is clicked because the tag corresponding to the Checkout button refers to thecheckoutmethod via itsactionattribute:<h:commandButton id="checkoutLink" value="#{CBMessages.Checkout}" action="#{CoffeeBreakBean.checkout}" />The
checkoutmethod returns aString, which the JavaServer Faces page navigation system matches against a set of navigation rules to determine what page to access next. The navigation rules are defined in a separate XML file, described in the next section.Resource Configuration
A JavaServer Faces application usually includes an XML file that configures resources for the application. These resources include JavaBeans components, navigation rules, and others.
Two of the resources configured for the JavaServer Faces version of the Coffee Break server are the
CheckoutFormbean and navigation rules for theorderFormpage:<managed-bean> <managed-bean-name>checkoutFormBean</managed-bean-name> <managed-bean-class> com.sun.cb.CheckoutFormBean </managed-bean-class> <managed-bean-scope>request</managed-bean-scope> <managed-property> <property-name>firstName</property-name> <value>Coffee</value> </managed-property> <managed-property> <property-name>lastName</property-name> <value>Lover</value> </managed-property> <managed-property> <property-name>email</property-name> <value>jane@home</value> </managed-property> ... </managed-bean> <navigation-rule> <from-view-id>/orderForm.jsp</from-view-id> <navigation-case> <from-outcome>checkout</from-outcome> <to-view-id>/checkoutForm.jsp</to-view-id> </navigation-case> </navigation-rule>As shown in the
managed-beanelement, thecheckoutFormbean properties are initialized with the values for the user, Coffee Lover. In this way, the hyperlink tag fromorderFormis not required to submit these values in the request parameters.As shown in the navigation-rule element, when the
String,checkout, is returned from a method referred to by a component'sactionattribute, thecheckoutFormpage displays.