Section 19.3. The Development Process with Struts

19.3. The Development Process with Struts

Prefatory to creating a Struts application, you must do three basic things. First, determine what views will be displayed, especially the forms in the application, the data they will collect, and the actions that will be linked to the data collected. Second, record those decisions in an XML configuration file for the Struts controller (struts-config.xml), representing the forms and actions. Third, write the classes representing the forms and actions. It is crucial to note that different developers may tackle these tasks in a different order. If you are working from existing requirements, you would likely move straight to the XML configuration file. If application flow and data may be defined piecemeal, you might start working on some form and action classes and integrate them gradually into your configuration file. If you are a new Struts developer, you will likely find that you are constantly moving back and forth between the configuration file, your views, and your Java code; you will also find that, while reading this chapter, you will need to move back and forth between the section discussing the Struts configuration file and the other aspects of a Struts project. This tension between what belongs in the configuration file and what belongs in the other resources has motivated a number of Struts tools such as IDE plug-ins, XDoclet templates, and so forth; but, as with many frameworks, until you have experienced the pain, you won't obtain much gain from using them.

Here is a sample to-do list for getting your Struts application off the ground:

Steps 1-4: Determine views, actions, and flow

1. Enumerate all of the views that will be sent to the browser. Typically these are JSP pages.

2. For each view with HTML form data, itemize the groups of parameters that actions will process. You will implement these as Struts ActionForm beans. At this point, you might also consider any validations that are required on these parameters.

3. Define all of the "actions" that your application must perform. Typically these are behaviors that respond to parameterized data submitted by an HTML form using the HTTP POST method. You will implement these as Struts Action classes.

4. Determine the flow of your application. To do this, you will need to decide on the possible outcomes of each page and to what other action or page control should be directed, according to each outcome.

Step 5: Configure

1. Write the Struts configuration file that defines for Struts the relationships between views (JSP), actions (Action classes), and groups of parameters (ActionForm classes).

Steps 6-7: Write code

1. Write your JSPs, Action classes, and ActionForm classes.

2. Compile your code and build your application for deployment.

Let's take a look at the sample application with this to-do list in mind and consider, in order, a view (item 1), its form data (item 2), the action that will respond to form data (item 3), and to what page the user should be directed after the form data has been processed (item 4). Items 5 and 6 will be addressed through the rest of the chapter. For item 7, compiling and building your application, see the file layout and Ant script with the code bundle.

After the librarian logs in (username: librarian; password: librarian), one option is to follow the Book Administration link and change the status of individual books from checked out to checked in or vice versa. Figure 19-1 shows what the page looks like in my browser.

Figure 19-1. Library administration page

Following our to-do list (and at the risk of being repetitive):

1. Clearly this is a dynamic view of some datathe books that are in the Library. One book is currently checked out: Crawford and Kaplan's J2EE Design Patterns (it must be a good one!). The view is represented with a JSP file, /view/adminbooks.jsp.

2. The form data for this view is the list of checkboxes in the third column. (Typically a form has a submit button; throughout the application, we detect changes in form inputs with JavaScript and submit the form immediately; this lends the application a more "event-driven" feel.) The form data is represented by a Java class, AdminBooksActionForm, extending the Struts ActionForm class.

3. When a checkbox's state is changed, Java code will change the state of an object that holds all the data pertinent to the Library. This action is represented by another Java class, AdminBooksAction, extending the Struts Action class.

4. Once the checkbox state changes have been registered in the Library, we return the user to this very page. In other words, the "forward" upon successful completion of the action is to /view/adminbooks.jsp. The relationship between the view, the form, the action, and the forward is represented by an ActionMapping, an object that is created by Struts when it reads its configuration file, struts-config.xml. If the user wants to go do something else, she clicks the Return Home link.