Professional Java.JDK.5.Edition (Wrox)

Chapter 8

private Phone phone; public AddContactAction() {

contact = new Contact(); phone = new Phone();

}

public String go() throws HibernateException { Query q =

getSession().createQuery(

“from Expertise exp where exp.id in (:ids)”); q.setParameterList(“ids”, selectedExpertises); contact.setExpertises(new HashSet(q.list())); contact.setPhone(phone); getSession().save(contact);

return SUCCESS;

}

The remainder of this code demonstrates just the conventional accessor and mutator methods of the object. Though frequently overlooked, and rarely considered very seriously, you must not forget them when they are necessary, and with two frameworks like Hibernate and WebWork that make such extensive use of reflection, they are very often necessary:

/**

* @return */

public Contact getContact() { return contact;

}

/**

* @return */

public Phone getPhone() { return phone;

}

/**

* @return */

public Integer[] getSelectedExpertises() { return selectedExpertises;

}

/**

* @param contact */

public void setContact(Contact contact) { this.contact = contact;

}

/**

* @param phone */

public void setPhone(Phone phone) { this.phone = phone;

}

/**

386

Developing Web Applications Using the Model 2 Architecture

* @param integers */

public void setSelectedExpertises(Integer[] integers) {

selectedExpertises = integers;

}

}

Of course, note that you could have written validation rules in your code, but instead it is easier to leverage XWork’s validation framework. Here is the validation XML file for this Action. It is pretty straightforward; you specify the types of validators that you wish to apply to each field, as well as a message if it fails. You can consult XWork’s documentation for all of its validation features:

<!DOCTYPE validators

PUBLIC “-//OpenSymphony Group//XWork Validator 1.0//EN” “http://www.opensymphony.com/xwork/xwork-validator-1.0.dtd”>

<validators>

<field name=”contact.firstName”> <field-validator type=”requiredstring”>

<message>You must enter a first name.</message> </field-validator>

</field>

<field name=”contact.lastName”> <field-validator type=”requiredstring”>

<message>You must enter a last name.</message> </field-validator>

</field>

<field name=”contact.email”> <field-validator type=”email”>

<message>Please correct the e-mail address.</message> </field-validator>

<field-validator type=”required”>

<message>Please enter an e-mail address.</message> </field-validator>

</field>

</validators>

These Action classes provide the core business logic of your application, but no application would be complete without considering the user interface.

Developing Your Views

Now, it is time to specify what the user will see as they traverse through the Web application. You will now describe your system’s user interface. Given different actions, what will the user see? In Figure 8-7, you have a drawing of how this Web application flows.

387

Chapter 8

SUCCESS

Figure 8-7

The flow starts with the default page of the Web application (specified just like any other J2EE Web application, in the web.xml file) — index.jsp. This page just serves as the front page for the application, which gives you links to your two major branches of the application: browsing contacts and adding contacts. Figure 8-8 shows you the simplicity of this page.

As you start to mock up your view elements, it becomes obvious that you will need to pull expertise data in order to populate the lists of expertise available in order to assign to a given contact, or by which to browse your contacts. Thus, based on these views, you have now derived two use cases in support of them.

388

Developing Web Applications Using the Model 2 Architecture

Figure 8-8

Often in situations like this one, where you have use cases specified simply to build the view, you will make a small departure from Model 2 purity and allow these pages to call their own application code specific to just building the view. WebWork provides the ability to reference its Actions and framework from within its WebWork JSP custom tags. However, for the sake of this chapter, since you used JSP custom tags extensively in the last chapter, you will use the pure approach.

Adding Contacts to the System

In order to browse the contacts in the system, first you must add some contacts to the system. Following the Add a Contact link on the Web application’s homepage leads you to this screen, displayed in Figure 8-9.

389

Chapter 8

Figure 8-9

Here is addContact.jsp, which renders the input form. The important point to take away from this important form is how it maps onto your Action class, right down to the internal attributes of its domain objects (like Contact and Phone).

<%@ taglib prefix=”ww” uri=”webwork” %> <jsp:include page=”index.jsp”/>

<table cellspacing=”0” cellpadding=”0” border=”0”> <tr>

<th>Enter Contact:</th> </tr>

<tr>

<td class=”mask”>

<ww:form name=”’createContactForm’” action=”’addContact.action’” method=”’POST’”>

<ww:textfield label=”’First Name’” name=”’contact.firstName’”/> <ww:textfield label=”’Last Name’” name=”’contact.lastName’”/> <ww:textfield label=”’Email’” name=”’contact.email’”/> <ww:textfield label=”’IM’” name=”’contact.im’”/>

<ww:textfield label=”’Phone Number’” name=”’phone.phoneNumber’”/> <ww:textfield label=”’Phone Type’” name=”’phone.phoneType’”/>

390

Developing Web Applications Using the Model 2 Architecture

<ww:select label=”’Expertise’” name=”’selectedExpertises’” listKey=”id”

listValue=”title”

list=”expertises”

multiple=”true”

/>

<ww:submit value=”’CREATE’” /> </ww:form>

</td>

</tr>

</table>

Of course, after you submit your new Contact, it brings you right back to the same page, with the form already filled in. This would be an ill-advised thing in production, but for a personal use system, it would probably save some data entry. Either way, in this case, you are just doing this to reduce the scope of the application so it can focus on the critical concepts of Model 2.

Browsing Contacts

Now that you have contacts, you can browse through them based on their expertise. Clicking on “Browse Contacts” leads you to the screen displayed in Figure 8-10.

Figure 8-10

391

Chapter 8

This page was built by using the Browse Contact Form use case, which provides an opportunity to demonstrate how to map the domain object into a Select box. Here is the code for browse.jsp. Note how the WebWork select tag maps to the List of Expertise objects that this page renders. The listKey attribute provides the value for each of the options within the HTML select, while the listValue provides the display value:

<%@ taglib prefix=”ww” uri=”webwork” %> <jsp:include page=”index.jsp”/>

<table cellspacing=”0” cellpadding=”0” border=”0”> <tr>

<th>Select an expertise:</th> </tr>

<tr>

<td class=”mask”>

<ww:form name=”’browseContactForm’” action=”’browseContacts.action’” method=”’POST’”>

<ww:select label=”’Expertise’” name=”’expertiseId’” listKey=”id”

listValue=”title”

list=”expertises”

/>

<ww:submit value=”’BROWSE’” /> </ww:form>

</td>

</tr>

</table>

When you submit this page, you get a table of contacts with their relevant information. This table is shown in Figure 8-11.

392

Developing Web Applications Using the Model 2 Architecture

Figure 8-11

This screen is rendered by browseContacts.jsp. In it you see the use of the WebWork iterator tags to traverse the list of contacts and print out the relevant details about each contact:

<%@ taglib prefix=”ww” uri=”webwork” %> <jsp:include page=”index.jsp”/>

<table cellspacing=”1” cellpadding=”1” border=””> <tr>

<th>Contacts</th>

</tr>

<tr>

<td class=”mask”>

<table cellspacing=”4” cellpadding=”4”>

<tr>

<th>Name</th> <th>E-mail</th> <th>IM</th>

<th>Phone Number (Type)</th> <th>Expertise</th> <th>Delete?</th>

</tr>

<ww:iterator id=”curContact” value=”contacts”>

393

Chapter 8

<tr>

<td>

<ww:property value=”firstName”/>, <ww:property value=”lastName”/> </td>

<td><a href=”mailto:<ww:property value=”email”/>”/> <ww:property value=”email”/>

</a></td>

<td>

<ww:property value=”im”/> </td>

<td>

<ww:property value=”phone.phoneNumber”/>

(

<ww:property value=”phone.phoneType”/> )</td>

<td>

<ww:iterator id=”expertiseCur” value=”expertises”>

<a href=”browseContacts.action?expertiseId=<ww:property value=”id”/>”> <ww:property value=”title”/>

<br>

</a>

</ww:iterator>

</td>

<td><a href=”deleteContact.action?selectedContact=<ww:property value=”id”/>”>

<b>Delete</b></a></td>

</tr>

</ww:iterator>

</table>

</td>

</tr>

</table>

Of course, the link to Delete will remove a given Contact from the database, but it returns the user back to the Browse Contacts screen, so it is unnecessary to review again.

Now that you have put together all of the components of a WebWork application, you need to review how to configure all of them to work together.

Configuring Your Application

In putting together all of these components that you have built using the WebWork framework, the first thing to remember is that WebWork is a J2EE Web application first and foremost. Therefore, it is useful to start with the Web application deployment descriptor, commonly called the web.xml:

<?xml version=”1.0” encoding=”ISO-8859-1”?>

<!DOCTYPE web-app

PUBLIC “-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN” “http://java.sun.com/dtd/web-app_2_3.dtd”>

<web-app>

394

Developing Web Applications Using the Model 2 Architecture

<display-name>Contact manager</display-name> <description>Example of Model 2 using Hibernate</description> <filter>

<filter-name>container</filter-name> <filter-

class>com.opensymphony.webwork.lifecycle.RequestLifecycleFilter</filter-class> </filter>

<filter-mapping> <filter-name>container</filter-name> <url-pattern>/*</url-pattern>

</filter-mapping> <listener>

<listener- class>com.opensymphony.webwork.lifecycle.ApplicationLifecycleListener</listener-cla ss>

</listener>

<listener> <listener-

class>com.opensymphony.webwork.lifecycle.SessionLifecycleListener</listener-class> </listener>

<servlet> <servlet-name>velocity</servlet-name> <servlet-

class>com.opensymphony.webwork.views.velocity.WebWorkVelocityServlet</servlet-class

>

<load-on-startup>1</load-on-startup> </servlet>

<servlet> <servlet-name>webwork</servlet-name> <servlet-

class>com.opensymphony.webwork.dispatcher.ServletDispatcher</servlet-class> </servlet>

<servlet-mapping> <servlet-name>webwork</servlet-name> <url-pattern>*.action</url-pattern>

</servlet-mapping> <servlet-mapping>

<servlet-name>velocity</servlet-name> <url-pattern>*.vm</url-pattern>

</servlet-mapping> <welcome-file-list>

<welcome-file>index.jsp</welcome-file> </welcome-file-list>

<taglib> <taglib-uri>webwork</taglib-uri>

<taglib-location>/WEB-INF/webwork.tld</taglib-location> </taglib>

</web-app>

Note that the WebWork wrapper to XWork is composed of a servlet filter, a listener, two servlets, and a tag library. You could always modify the mappings as you see fit, for example, if you prefer to make your actions more like those of Struts and end in .do, rather than .action.

395