Implement "New Contact" Function
Implement the new contact functionality so that the application will pass the NewTest test suite in addition to the ShowListTest test suite. The files you will need to create or change are:
The NewAction class simply populates the EditForm class with default values and then displays the JSP containing the HTML for the form. Some forms contain default values. In your case, no default values exist.
The EditForm class is a container for shuttling data between the persistence layer (the JavaBean classes that model data in the database) and the presentation layer (the JSPs or HTML forms that display information and accept input from a browser). The reason that Struts form classes are useful is that the persistence layer oftentimes has differences in data type or cardinality from the presentation layer. As a concrete example, consider the case of a date value. In most databases, a date is stored as a single field that contains the month, day, and year. In Java, you store a date in a java.util.Date object. Most people consider it easier to enter dates with three drop-down fields or two drop-down fields and one text field. Month and day are usually drop-down fields. Year is occasionally a drop-down field, but sometimes a text field. Even if you asked the user to enter the date as a single field, you still have to deal with type conversion because standard Web forms can transfer only string data.
The edit.jsp file contains the HTML for the form, including a section at the top for display of input errors and the Struts tags to render HTML input fields. The reason you use edit.jsp rather than creating a separate file called new.jsp is that the form for creating a new contact is exactly the same as the form for editing an existing contact with several exceptions, including the following:
- The new contact form does not have a value for the hidden ID field that identifies the record being edited.
- The new contact form may have a different page title or a different table heading than the edit contact form (e.g., "New Contact" vs. "Edit Contact").
Make the following changes:
- Copy NewAction.java.v1 from the example code archive to src/WEB-INF/classes/com/abcinc/phonelist and name the file NewAction.java.
- Copy EditForm.java.v1 from the example code to src/WEB-INF/classes/com/abcinc/phonelist and name the file EditForm.java.
- Copy edit.jsp.v1 from the example code to src/web and name the file edit.jsp.
- Add the following section to struts-config.xml in the section right after the entry for manageForm:
- Add the following sections to struts-config.xml in the section:
<forward name="success" path="edit"/>
<forward name="inputProblem" path="edit"/>
<forward name="success" path="showList"/>
<forward name="cancel" path="showList"/>
The reason you need to define "/save" right now is that you use "/save" as the action attribute of the HTML form in edit.jsp. Struts requires that action mapping definitions exist before defining HTML forms that refer to those action mappings.
- Add the following section to tiles-defs.xml:
<definition name="edit" extends="mainLayout">
<put name="titleString" value="Phone List :: Edit Contact"/>
<put name="body" value="/edit.jsp"/>
<put name="bodyParam1" value="Edit" direct="true"/>
- Copy ApplicationResources.properties.v1 from the example code to src/WEB-INF/classes/com/abcinc/phonelist and name the file ApplicationResources.properties. The ApplicationResources.properties file stores string resources for Struts, primarily the labels of fields and error messages. Having all of the labels, error messages, and other visible text in a file makes it easy to internationalize the application. In order to create a version in Russian or French or German for example, all you have to do is translate the text and create a separate ApplicationResources.properties file (with a suffix denoting the locale). The Web application will automatically use the appropriate file based on the locale.
At this point, your struts-config.xml file should be equivalent to struts-config.xml.v3 from the example files, except for formatting and comments. Your tiles-defs.xml file should be equivalent to tiles-defs.xml.v3, except for formatting and comments.
Now perform the following steps:
- Shut down Tomcat by typing ./shutdown.sh in the bin subdirectory of the Tomcat distribution directory.
- Run ant undeploy. If you don't run ant undeploy, the unpacked directory tree for the phonelist application remains in the Tomcat deploy directory. Consequently, when Tomcat restarts it does not bother unpacking the revised version of the phonelist application from the phonelist.war archive. Thus, it will appear that the application never changes.
- Run ant deploy.
- Start up Tomcat by typing ./startup.sh in the bin subdirectory of the Tomcat distribution directory.
Perform the new tests by typing ant test. Most of your tests should pass, with the exception of the testSaveNewContact test case in the NewTest test suite. This is natural since you didn't implement the SaveAction. Testing is designed to catch goofs like this.
Go back and remedy the problem by performing the following steps:
- Copy SaveAction.java.v1 from the example code to src/WEB-INF/classes/com/abcinc/phonelist and name the file SaveAction.java.
- Copy validation.xml.v2 from the example code to src/WEB-INF and name the file validation.xml, replacing your existing version of validation.xml. Although not necessary, this helps with checking input in the new/edit contact form to ensure that proper values are entered. The validation at this point consists solely of mandating that the first and last names are entered.
Now re-run the tests by typing ant test in the phonelist project directory. All of the tests should pass.