Learning Jakarta Struts, Part 2

This is the second article in a three-part series on the Struts framework. In the first article, Introduction to Jakarta Struts Framework I defined the Struts framework, discussed what it can accomplish, and provided an overview of the various components used throughout the framework. In this article I describe building a simple sample application from scratch using Struts 1.0. The third article will show you how to use the Struts tags to access the ApplicationResource file from a JSP.

Taking a step-by-step approach should open some new doors and show the potential of using Struts in your application development. If you aren't familiar with Struts terminology, take a quick read through the introductory article.

This article assumes a working knowledge of JSP, Servlets, Custom Tag libraries, and XML. Additionally, I will be using a number of Jakarta projects throughout this article, including Tomcat 3.2.1, the servlet container used in the official reference implementation for the Java Servlet and JSP technologies (the latest version, 3.2.3, implements some security fixes to 3.2.1), and Ant, a Java-based build tool.

As a developer who has written hundreds of applications using leading- (and usually bleeding-) edge technology, I am a strong believer in understanding the logical flow of new technology development. While it's possible to just dive in and learn as you go (which all of us are guilty of), I'd like to take this opportunity to go through a typical development flow when using Struts. I'll apply this development flow to our simple sample, but you will be able to apply these steps to larger, more complicated development scenarios. I have followed these steps on large projects, and they work.

Anyone who has written a business or Web application knows the requirements list is always somewhat dynamic; having a development flow to follow will at least help you identify what additional tasks need to be added to the list. Let's list the flow, and then I will explain and apply it to our sample.

Throughout this article I will be using code snippets from the StrutsSample application. The full code, including the build.xml file to build and deploy the application, is available for download here.

Struts Development Cycle

As you can tell by the release number, Struts is relatively new. There are a number of components that work together, but knowing when you have to complete each component can save much time, to say nothing of your sanity. I've written a number of applications that utilize Struts, and I've found that following an approach similar to this one is effective:

1. Gather and define the application requirements.
2. Define and develop each screen requirement in terms of data collected or displayed.
3. Determine the access path for each screen.
4. Define the ActionMappings that correlate to the application business logic.
5. Develop any classes or APIs that are necessary to meet screen requirements.
6. Create the ActionForms with defined properties from the screen requirements (this can include the validation portions as well).
7. Develop Actions to be called by the ActionMappings, which in turn call the appropriate helpers and forward to JSPs.
8. Develop the application business logic (Beans, EJBs, etc).
9. Create JSPs to match the workflows using the ActionMappings.
10. Build the appropriate configuration files -- struts-config.xml, web.xml.
11. Build/test/deploy.

Gather and define the application requirements

The first step in any application development is to gather the application requirements. However logical this might sound, it is sometimes harder then it seems. Having a written set of requirements is important not just for development purposes, but also for identifying places that need further definition.

The application requirement for our project StrutsSample is as follows:

Provide a sample application allowing a user to log in, in order to demonstrate a complete logic flow using the Struts framework. Do not bog the sample down with concerns about security, database interaction, EJB development or any other ancillary technology that might be used in a more complicated application.

Define and develop each screen requirement in terms of data collected or displayed.

This application will have three screens:

• A login screen that allows for username and password entry.
• A welcome page that acknowledges successful login by displaying the username.
• An error page indicating a failed login.