Introduction to Jakarta Struts Framework
Pages: 1, 2
The model is an object that takes the request from the user and stores the results for the duration of the process. Usually a JavaBean passes along the information in the process. Model objects are typically application specific since they are basically the business logic of the application. Struts provide the ActionForm and Action classes, which extends to model objects creation. It is in these model objects where form validation, or any type of preprocessing of request data that is necessary, usually takes place. It's possible to have a one-to-one correlation between model objects and request pages, but it's not necessarily required. It's also quite possible to reuse a model object for multiple page requests. If there is no action necessary for a model object, the controller can send the request directly to the view object, as specified in the
struts-config.xml file is really the glue of the entire framework. While
web.xml defines where a request should go upon arriving,
struts-config.xml determines exactly what will happen to it. It's the Vito Corleone of the Struts framework; nothing happens without its okay and knowledge. This is where the mappings of actions are defined. As with the growing number of XML configuration files, the advantage of using one is in keeping a system modular and easy to maintain. It prevents the hard coding of objects to be called within a component. Changes can be made on the fly by changing the configuration files without having to re-deploy applications.
The controller uses the
struts-config.xml file to determine which object to call for a given action request. The file is read on startup and the relationships are stored in memory for optimal performance. A bare minimal
struts-config.xml is shown below. This just defines a login action so that when a login request is received, it will be forwarded to an instance of the action object
com.oreilly.ui.authentication.actions.LoginAction. The return of that class will determine which page to forward to from there. This sample also illustrates the ability to forward to other model objects; otherwise, it returns back to a view object, in this case the
<?xml version="1.0" encoding="ISO-8859-1" ?>
<!DOCTYPE struts-config PUBLIC
"-//Apache Software Foundation//DTD Struts Configuration 1.0//EN"
<!-- ========== Action Mapping Definitions=================== -->
<!-- Attributes of the <action> element -->
type - Fully qualified Java class name of the Action
implementation class used by this mapping.
name - The name of the form bean defined in the config
file that this action will use
path - The request URI path that is matched to select this
mapping unknown - Set to true if this action should be
configured as the default for this application to
handle all requests not handled by another action.
Only one action can be defined as a default within
a single application.
validate - Set to true if the validate() method of the
action associated with this mapping should be called.
<!-- ~~~~~~~~~~~~~~~~~~~~~ -->
<!-- O'Reilly Main Actions -->
<!-- ~~~~~~~~~~~~~~~~~~~~~ -->
<forward name="success" path="/DisplayMainPage.action"/>
<forward name="failure" path="/login.jsp"/>
The view object is often a JSP page. The Struts framework doesn't actually provide the JSP, but it does provide a number of tag libraries that easily allow JSP integration into the Struts framework. The interaction of Struts with JSP allows for storing data of an input form in a form bean; that is the ActionForm we mentioned earlier. The ActionForm is, then, used by the Action class for doing field validation. If errors are found during validation, there is a shared mechanism available in the framework for raising and displaying error messages.
The Struts framework includes a number of custom tag libraries, which are used in a variety of ways. While the use of these libraries is not required to use the framework, chances are that you will want to explore them. These libraries include:
n struts-htmltag library - used for creating dynamic HTML user interfaces and forms.
n struts-beantag library - provides substantial enhancements to the basic capability provided by
n struts-logictag library - can manage conditional generation of output text, looping over object collections for repetitive generation of output text, and application flow management.
n struts-templatetag library - contains tags that are useful in creating dynamic JSP templates for pages which share a common format.
Additionally, the custom tags in the Struts framework use the internationalization features built into the Java platform by using resource files. To provide messages for another language, simply add another resource file.
Strutting Your Stuff
The Struts framework, while relatively new, is definitely holding its own with developers. It's found in a number of applications, and can assist you with new development or existing JSP projects you might be working on.
For example, in a large database application such as the one I am working on for a client, the business-logic beans are implemented as EJBs. A JSP is displayed in the browser. Depending on the form that is being displayed, a specific action takes place, as defined in the
struts-config.xml file. The appropriate action class receives the request, does some validation on the form object, and calls the execute method of the appropriate EJB service bean. The results from the EJB are returned in XML that is then parsed. The content is stored in a form bean and then displayed by a JSP.
The entire control of the flow is done by the
struts-config.xml file, depending on return values from the various action classes. This is all centrally located and easy to adjust. Neither the action's servlet nor the JSP need to know (and in proper n-tier development, shouldn't have to care) where the result set that is being displayed comes from.
The only drawback that I've found with the framework from my current project is this: since it is a large-scale project, there are many screens and many request types. It seems that there are many Action classes, since we basically need only one per request type. I think that this could be avoided by doing some careful planning upfront, but for new product development it isn't always possible to identify the common requests. That information gets acquired over time as the application takes shape and new business requirements are defined. Of course, there weren't many Struts samples to use six months ago, either. That one issue aside, Struts has helped save time in coding an entire MVC model, and has definitely been stable enough to use and benefit from in production products.
In Part Two of this series, we will walk through building a simple Struts application and tie all of the pieces together in a coding sample.
Read more JSP and Servlets columns.
Return to ONJava.com.