struts

Exploring the Struts architecture

Talking the talk

This chapter explores the Struts framework in depth and highlights the benefits Struts can bring to your development efforts. We believe that once you can “talk the talk” of web architecture and design, you will be better equipped to use Struts with your own applications.

With a sound overview of the Struts architecture in place, we outline the Struts control flow and the way it handles the request-response event cycle. A good understanding of this process makes it much easier to create applications that make the best use of the framework.

Choosing a web application framework should not be a casual decision. Many people will use this book, and especially this chapter, as part of evaluating Struts for their project. Accordingly, we conclude this chapter with a candid look at the strengths and weaknesses of the Struts framework and address concerns regarding overall performance. Struts is designed for professional developers. To make informed decisions, professionals need to be aware of both a tool’s capabilities and its limitations.

Why we need Struts

Today’s web applications are critical components of the corporate mission. As always, development teams need to build applications in record time, but they have to build them right and build them to last.

Java web developers already have utilities for building presentation pages, such as JavaServer Pages and Velocity templates. We also have mechanisms for handling databases—JDBC and Enterprise JavaBeans (EJBs), for example. But what do we use to put these components together? We have the plumbing and the drywall … what else do we need?

One step back, three steps forward

In the late 1970s, when graphical user interfaces (GUIs) were being invented, software architects saw applications as having three major parts: the part that manages data, the part that creates screens and reports, and the part that handles interactions between the user and the other subsystems [Ooram]. In the early 1980s, the ObjectWorks/Smalltalk programming environment introduced this triumvirate as a development framework. In Smalltalk 80 parlance, the data system

is dubbed the Model , the presentation system is called the View , and the interaction system is the Controller . Many modern development environments, including Java’s Swing, use this Model/View/Controller (MVC) architecture (see figure 2.1) as the foundation of their own frameworks.

 

Figure 2.1 The Model/View/Controller architecture

Java web developers already have capable tools, such as JDBC and JSP, for consulting

the Model and creating the View, but where’s the Controller for our web applications?

Enter Struts

The centerpiece of Struts is an MVC-style Controller. The Struts Controller bridges the gap between Model and View. The framework also includes other missing pieces developers need to write scalable, leading-edge web applications. Struts is a collection of “invisible underpinnings” that help developers turn raw materials like databases and web pages into a coherent application.

Struts controller components

The Struts controller is a set of programmable components that allow developers to define exactly how their application interacts with the user. These components hide nasty, cumbersome implementation details behind logical names. Developers can program these details once, then go back to thinking in terms of what the program does rather than how it does it.

Users interact with a web application through hyperlinks and HTML forms. The hyperlinks lead to pages that display data and other elements, such as text and images. The forms generally submit data to the application via some type of custom action.

As shown in figure 2.2, Struts provides components that programmers can use to define the hyperlinks, forms, and custom actions that web applications use to interact with the user. We used these components to build a starter application in chapter 1. In chapter 3, we walk through using these components to build another simple application. Then, in chapter 4, we provide a detailed overview of configuring these components. Later chapters provide more detail about putting each component to use within your application. In part 4 we demonstrate using the components in the context of working applications. But, since this chapter is the architectural overview, let’s go ahead and introduce the major Struts components now.

 

Figure 2.2 Major Struts components

Hyperlinks

To the application developer, a hyperlink is a path to some resource in the application. This may be a web page or a custom action. It may also include special parameters. In Struts, developers can define a hyperlink as an ActionForward . These objects have a logical name and a path property. This lets developers set the path and then refer to the ActionForward by name.

ActionForwards are usually defined in an XML configuration file that Struts reads when the web application loads. Struts uses the XML definitions to create the Struts configuration, which includes a list of ActionForwards. The XML element that would create an ActionForward for a welcome hyperlink might look like this:

<forward

name="welcome"

path="/pages/index.jsp"/>

This element would create an ActionForm JavaBean with its name property set to welcome and its path property set to /pages/index.jsp.

JSP pages and other components can then refer to the welcome forward. The Struts framework will look up the welcome ActionForward bean and retrieve the path to complete the hyperlink. This allows developers to change the destination of a link without changing all the components that refer to that link. In most web applications, details like this are hardcoded into JSP and Java code, making changes difficult and prone to error. In a Struts application, these details can be changed throughout the application without touching a single page or Java class.

For more about ActionForwards, see chapter 6.

HTML forms

The web protocols, HTTP and HTML, provide a mechanism for submitting data from a form but leave receiving the data as an exercise for the developer. The Struts framework provides an ActionForm class, which is designed to handle input from an HTML form, validate the input, and redisplay the form to the user for correction (when needed), along with any corresponding prompts or messages.

ActionForms are just JavaBeans with a couple of standard methods to manage the validation and revision cycle. Struts automatically matches the JavaBean properties with the attributes of the HTML controls. The developer defines the Action- Form class. Struts does the rest.

This class will automatically populate the username field from a form with an HTML form element of the same name, as shown here:

public final class LogonForm extends ActionForm {

private String username = null;

public String getUsername() {

return (this.username);

}

public void setUsername(String username) {

this.username = username;

}

}

Other properties would be added for each field of the form. This lets other components get what they need from a standard JavaBean, so everyone does not have to sift through an HTTP request.

The ActionForm classes are created using normal Java classes. The Struts configuration refers to the ActionForm classes through a set of descriptors: the <form-beans> and <form-bean> elements. The <form-bean> elements are descriptors that the framework uses to identify and instantiate the ActionForm objects, as shown here:

<form-bean

name="articleForm"

type="org.apache.artimus.struts.Form"/>

The Struts configuration lists the ActionForm beans it uses and gives the Action- Form classes a logical name to use within the application. For more about ActionForms, see chapter 5.

Custom actions

An HTML form uses an action parameter to tell the browser where to send the form’s data. The Struts framework supplies a corresponding Action class to receive such data. The framework automatically creates, populates, validates, and finally passes the appropriate ActionForm to the Action object. The Action can then get the data it needs directly from the ActionForm bean.   ere’s an example:

public final class LogonAction extends Action {

public ActionForward perform (ActionMapping mapping,

ActionForm form,

HttpServletRequest request,

HttpServletResponse response)

throws IOException, ServletException {

MyForm myForm = (MyForm) form;

// ...

return mapping.findForward("continue");

}

}

An Action concludes by returning an ActionForward object to the controller. This allows the Action to choose a definition using logical names, like continue or cancel , rather than system paths.

To ensure extensibility, the controller also passes the current request and response object. In practice, an Action can do anything a Java Servlet can do. For more about Action objects, see chapter 8.

In addition to the ActionForward, ActionForm, and Action objects, the Struts controller layer provides several other specialized components, including Action- Mappings and the ActionServlet . Struts also supports localizing your application from the controller layer.

ActionMappings

In a web application, every resource must be referred to through a Uniform Resource Identifier (URI). This includes HTML pages, JSP pages, and any custom actions. To give the custom Actions a URI, or path, the Struts framework provides an ActionMapping object. Like the ActionForwards and ActionForms, the mappings are usually defined in the XML configuration file:

<action-mappings>

<action

path="/logonSubmit"

type="app.LogonAction"

name="logonForm"

scope="request"

validate="true"

input="/pages/logon.jsp"/>

</action-mappings>

This also allows the same Action object to be used by different mappings. For example, one mapping may require validation; another may not.

For more about ActionMappings, see chapter 7.

ActionServlet

The Struts ActionServlet works quietly behind the scenes, binding the other components together. Although it can be subclassed, most Struts 1.0 developers treat the ActionServlet as a blackbox: they configure it and leave it alone. For more about configuring Struts, see chapter 4.

In Struts 1.1, the ActionServlet is easier to extend. Chapter 9 covers the new extension points and configuration options for the Struts 1.1 ActionServlet.

Localization

Web applications also interact with users through prompts and messages. The Struts components have localization features built in so that applications can be written for an international audience. We refer to the localization features throughout the book. A general overview is provided in chapter 13.

Developing a web application with Struts

To build a web application with Struts, developers will define the hyperlinks they need as ActionForwards, the HTML forms they need as ActionForms, and whatever custom server-side actions they need as Action classes.

Developers who need to access EJBs or JDBC databases can do so by way of the Action object. This way, the presentation page does not need to interact with the Model layer.

The Struts Action object will collect whatever data a View may need and then forward it to the presentation page. Struts provides a JSP tag library for use with JSP pages that simplifies writing HTML forms and accessing other data that an Action may forward. Other presentation devices, such as Velocity templates, can also access the Struts framework to create dynamic web pages. This process is shown in figure 2.3.

 

Figure 2.3 Delivering data back to the view

For more about using various data systems with Struts, see chapter 14. See chapters 10 and 11 to learn more about creating presentation pages with Struts.

Before moving deeper into the Struts architecture, let’s take a look at the issues faced by a web application framework that the architecture must address.