Wizard API updated!
Tim Boudreau has released a new version of the Swing Wizard library (version 0.997) that fixes the WizardException bug reported in JavaWorld's recent Open Source Java Project profile. The article's examples have been reworked to test out the new, improved WizardException. Thanks, Tim, for this helpful fix!
Open Source Java Projects: The Wizard API

Newsletter sign-up

Sign up for our technology specific newsletters.

Enterprise Java
View all newsletters

Email Address:

Jump the hurdles of Struts development

Tips for solving common difficulties in Struts

Unless you have been living under a rock or in a cave for the past few years, you have most likely heard of the Struts framework. Struts is the open source initiative sponsored by the Apache Software Foundation and was created to encourage the Model-View-Controller (MVC) design paradigm within a Web application's presentation layer. Struts implements the MVC pattern using the Service to Worker pattern. A well-designed architecture strives to be loosely coupled and highly cohesive. Struts provides the mechanism to achieve this design goal in the presentation layer of multitiered, enterprise Web applications.

One of the most daunting tasks facing enterprise application architects is the presentation layer's creation and maintenance. Users expect highly functional, robust, and elegant graphical user interfaces. Thus, the presentation layer's codebase winds up greatly outnumbering that of the application layer. In addition, the advent of different display platforms such as wireless phones and PDAs has made an already complex situation much more complex.

Various books and articles already cover Struts's inner workings and teach how to use the framework. This article elaborates on the issues facing Web application developers who use Struts and how to resolve them. Many of the following approaches can be abstracted and applied to different MVC frameworks such as the upcoming JavaServer Faces specification. Craig R. McClanahan, one of the original creators of Struts, leads that specification.

This discussion's topics cover those areas that present the most hurdles while building a J2EE (Java 2 Platform, Enterprise Edition) application using Struts with BEA WebLogic Server. We cover the following specific issues:

  • Creating/maintaining struts-config.xml
  • Form/session management
  • Relationships of Struts mappings and the user interface
  • Managing the Back button
  • User authentication
  • User interface control flow
  • Exception handling
  • Testing


Take two and call us in the morning

The Struts framework unarguably eases the development and maintenance of user interfaces for enterprise applications. However, after working with Struts on even a simple application, one quickly realizes the nightmare that is struts-config.xml. That file can quickly become unwieldy at best. When building an enterprise application, struts-config.xml can grow in excess of 500 action mappings, making it virtually unmanageable.

We recommend two tools to help manage this headache. First, document your user interface flow using Microsoft Visio and StrutsGUI from Alien-Factory. StrutsGUI is a Visio stencil that helps depict user interface flow diagrams using Struts nomenclature. There is a hidden gem within the Struts stencil item: by right-clicking this option, selecting Edit Title Properties, and then selecting the Tools option, you can generate a struts-config.xml file based on this diagram. For example, the simple application shown in Figure 1 generates the following struts-config.xml shown in the code below:

Figure 1. StrutsGUI model. Click on thumbnail to view full-size image.

<?xml version="1.0" encoding="ISO-8859-1" ?>
<!-- Struts Config XML - Sample Struts App -->
<!-- ===================================== -->
<!-- AutoGenerated from : c:\dev\javaworld\app\sample.vsd -->
<!-- AutoGenerated on   : 02-18-2003 23:05:47 -->
<!-- AutoGenerated by   : Struts GUI v2.11   (c)2002 Alien-Factory -->
<!--                    : See 'http://www.alien-factory.co.uk' for details -->
<!-- GET YOUR STICKY FINGERS OFF! i.e. Do not edit. -->
<!DOCTYPE struts-config PUBLIC
      "-//Apache Software Foundation//DTD Struts Configuration 1.0//EN"
      "http://jakarta.apache.org/struts/dtds/struts-config_1_0.dtd">
<struts-config>
  <!-- ====================== Form Bean Definitions =================== -->
  <form-beans>
  </form-beans>
  <!-- ================= Global Forward Definitions =================== -->
  <global-forwards>
  </global-forwards>
  <!-- ======================= Action Definitions ===================== -->
  <action-mappings>
    <action  path="/Login"
             type="com.agilquest.onboard.presentation.actions.LoginAction">
      <description>Authenticates and authorizes a user.</description>
    </action>
  </action-mappings>
  
</struts-config>


To make your user interface flow diagrams more complete, we recommend an additional step when using StrutsGUI. Within your StrutsGUI Visio document, you can easily link each JSP (JavaServer Pages) page to its actual screen shot in the application. Not only does creating this artifact aid in documenting the application, but more importantly, it becomes an excellent tool for training new developers about the user interface design.

Another tool that helps manage Struts applications is the Struts Console created by James Holmes. In essence, it provides facilities that enable you to get to the same endpoint as StrutsGUI, but differs in approach and strengths. Both tools perform well, and either will enhance a Struts-based enterprise application's maintenance.

Now, where did I put that form?

ActionForm session management can be tricky. What should the ActionForm's life be? Should it be in request scope or session scope? One solution to this problem puts the ActionForm in session for the life of the functionality it is supposed to represent.

In such a case, how do you maintain these ActionForm objects generically? Who assumes the responsibility of cleaning up these ActionForm objects once they are no longer needed? A typical scenario is when a user traverses from one functionality to another through a menu. In that case, the old ActionForm objects should be removed from the session and new ActionForm objects created. A centralized Action class, called MenuAction, which deals only with the menu traversal, should be present. This Action class deletes the redundant ActionForm objects from the session. It then forwards the user to the new page where new ActionForm objects are created.

Given this, how do we show the different menu items to the user based on her role or permissions? This menu should also be internationalized, and it can change based on the user permissions; that is, if the permissions change, the menu must change accordingly. One such approach persists the user's permissions. When she logs in, a MenuFactory creates menus from these permissions. For additional safety, the MenuAction class can then authorize the user before permitting her to proceed to the selected functionality.

1 | 2 | 3 | 4 | 5 | 6 |  Next >
Resources