email article printer friendly more resources

Struts Provides Support for Dynamic Content
Handle dynamic content for rendering Web pages by employing the Struts framework's new feature for supporting different types of forms
by Sharad Acharya

November 12, 2003

Most J2EE-compliant Web applications are based on the Model-View-Controller (MVC) architecture. A Model component encapsulates application state, notifies views about changes, responds to state query, and exposes application functionality. In general, it is the application data and business logic operating in those data. A View component renders the model, sends user gesture to a controller, and allows a controller to select views. A Controller component defines application behavior, maps user actions to model updates, and selects view to respond.

The Struts framework follows the MVC pattern architecture. It defines ActionServlet as a controller component that can be used directly as a controller or subclassed to add application-specific behavior, if needed. ActionForm is the class that can be extended to define custom action forms as a model component. An application can define one or more JavaServer Pages (JSP) as view components. This framework is part of the Jakarta project, and it is in version 1.1 at the time of this writing (see Resources for downloads, documentation, and other resources at the Struts Web site.)

In this first installment, we'll look at how to handle dynamic contents to render a Web page under the Struts Framework, and then we'll move on to DynaActionForms and their advantage over normal ActionForms. In the final installment of this article we'll discuss Map-backed forms and how to handle dynamic contents using such forms. Liberal examples of code will illustrate these concepts. The contents discussed here are supported by Struts version 1.1 (beta) and later. The code was tested in a WebSphere Studio Application Developer (WSAD) Version 5.0 Enterprise Edition test environment.

The Struts framework defines actions what we'll call unit of work. Any user action (such as clicking a button on a screen) gets translated to some Struts action, which is defined at struts-config.xml (or the configuration file, which is how we'll refer to it from this point onward).

ActionServlet is the component that initializes and keeps track of all action mappings defined in the configuration file. Once it intercepts a request, it inspects the request object and invokes an appropriate action() method in the Action class defined in the action mapping. The Controller servlet makes sure that ActionMapping instances are created before it handles the first Struts request. Let's look at an example of a simple survey form. In the tag of configuration file, an action is defined in an action tag under an action-mappings tag:

<action-mappings>
  <action path="/survey" 
    name="surveyForm"
    type="actions.SurveyAction"
      input="survey.jsp">
  <forward name="success" 
    path="thankyou.jsp">
  </forward>
  </action>
</action-mappings>

For this mapping, the Struts controller creates an ActionMapping instance represented by the path attribute. The input represents the input JSP, which is used to forward in case there are any validation errors. In order, the controller: 1) before rendering the page specified as input, calls the reset() method in ActionForm (surveyForm in this example) if it is present; 2) calls the reset() method once again when the user submits an action; 3) populates the user-entered data for matching form fields by calling setter methods; 4) calls the validate() method in the ActionFrom (surveyForm in this example) instance if it is present; 5) calls the execute() method in the Action class (SurveyAction in this example) for this action; and 6) based on the return value from execute(), forwards control to the appropriate page (thankyou.jsp in this example).