Chapter 4: Actions and ActionServlet

 < Day Day Up > 



In this chapter, we dig further into the Controller components of the Struts Framework. We begin by looking at four distinct Struts Controller components: the ActionServlet class, the Action class, Plugins, and the RequestProcesser.

The goal of this chapter is to provide you with a solid understanding of the Struts Controller components and how they can be used and extended to create a robust and easily extended Web application.

The ActionServlet Class

The org.apache.struts.action.ActionServlet is the backbone of all Struts applications. It is the main Controller component that handles client requests and determines which org.apache.struts.action.Action will process each received request. It serves as an Action factory—creating specific Action classes based on the user's request.

While the ActionServlet sounds as if it might perform some extraordinary magic, it is a simple servlet. Just like any other HTTP servlet, it extends the class javax.servlet.http.HttpServlet and implements each of the HttpServlet's lifecycle methods, including the init(), doGet(), doPost(), and destroy() methods. The two main entry points into the ActionServlet are essentially the same as with any other servlet: doGet() and doPost(). The source for both of these methods is shown here:

 public void doGet(HttpServletRequest request,   HttpServletResponse response)   throws IOException, ServletException {   process(request, response); } public void doPost(HttpServletRequest request,   HttpServletResponse response)   throws IOException, ServletException {   process(request, response); } 

Notice that the implementation of these two methods is exactly the same. They call a single method, named process(). The Struts-specific behavior begins with this method. The process() method handles all requests and has the following method signature:

 protected void process(HttpServletRequest request,   HttpServletResponse response); 

When the ActionServlet receives a request, it completes the following steps:

  1. The doPost() or doGet() methods receive a request and invoke the process() method.

  2. The process() method gets the current RequestProcessor and invokes the RequestProcessor. process() method.

    start sidebar

    If you intend to extend the ActionServlet, the most logical place for customization is in the RequestProcessor object. It contains the logic that the Struts controller performs with each request. We discuss the RequestProcessor near the end of this chapter.

    end sidebar

  3. The RequestProcessor.process() method is where the current request is actually serviced. This method retrieves, from the struts-config.xml file, the <action> element that matches the path submitted on the request. It does this by matching the path passed in the <html:form /> tag's action element to the <action> element with the same path value. Here's an example of this match:

     <html:form action="/Lookup"   name="lookupForm"   type="ch04.LookupForm" > <action path="/Lookup"   type="ch04.LookupAction"   name="lookupForm" >   <forward name="success" path="/quote.jsp"/>   <forward name="failure" path="/index.jsp"/> </action> 

  4. When the RequestProcessor.process() method has a matching <action>, it looks for a <form-bean> entry that has a name attribute that matches the <action> element's name attribute. The following code snippet contains a sample match:

     <form-beans>   <form-bean name="lookupForm"     type="ch04.LookupForm"/> </form-beans> <action path="/Lookup"   type="ch04.LookupAction"   name="lookupForm" >   <forward name="success" path="/quote.jsp"/>   <forward name="failure" path="/index.jsp"/> </action> 

  5. When the RequestProcessor.process() method knows the fully qualified name of the FormBean, it creates or retrieves a pooled instance of the ActionForm named by the <form-bean> element's type attribute and populates its data members with the values submitted on the request.

  6. After the ActionForm's data members are populated, the RequestProcessor.process() method calls the ActionForm.validate() method, which checks the validity of the submitted values.

    start sidebar

    There is more to the validate() method—you see how this method is configured and performs in Chapter 10, "Managing Errors."

    end sidebar

  7. At this point, the RequestProcessor.process() method knows all that it needs to know and it is time to actually service the request. It does this by retrieving the fully qualified name of the Action class from the <action> element's type attribute, creating or retrieving the named class, and calling the Action.execute() method. We look at this method in the section titled "The Action Class," later in this chapter.

  8. When the Action class returns from its processing, its execute() method returns an ActionForward object that is used to determine the target of this transaction. The RequestProcessor.process() method resumes control, and the request is then forwarded to the determined target.

  9. At this point, the ActionServlet instance has completed its processing for this request and is ready to service future requests.

Configuring the ActionServlet

Now that you have a solid understanding of how the ActionServlet performs its duties, let's take a look at how it is deployed and configured. The ActionServlet is like any other servlet and is configured using a web.xml <servlet> element.

You can take many approaches when setting up an ActionServlet. You can go with a bare-bones approach, as we did in Chapter 3, "Getting Started with Struts," or you can get more serious and include any combination of the available initialization parameters described in Table 4.1.

Table 4.1: The Initialization Parameters of the ActionServlet

Parameter

Description

config

Names the context-relative path to the struts-config.xml file. The default location is in the /WEB-INF/struts-config.xml directory. (Optional)

config/${module}

Names the context-relative path to the struts-config.xml file associated with a particular Struts Module. (Optional)

convertNull

A boolean parameter used to simulate Struts 1.0x functionality when populating an ActionForm. When this parameter is set to true, numeric objects (java.lang.Integer, etc.) are initialized to null. If it is set to false, these objects are set to 0.

debug

Determines the debugging level for the ActionServlet. The default value is 0, which turns debugging off. (Optional)

detail

Sets the debug level for the Digester object, which is used during ActionServlet initialization. The default value is 0. (Optional)

multipartClass

Names the fully qualified class of the MultipartRequestHandler implementation to be used when file uploads are being processed. The default value is org.apache.struts.upload.DiskMultipartRequestHandler. (Optional)

validating

If set to true, tells the ActionServlet that we want to validate the strut-config.xml file against its DTD. While this parameter is optional, it is highly recommended and therefore the default is set to true.

While none of these initialization parameters are required, a couple of the more common ones are the config and debug parameters. It is also common practice to use a <load-on-startup> element to ensure that the ActionServlet is started when the container starts the Web application. An example <serlvet> entry, describing an ActionServlet, is shown in the following code snippet:

 <servlet>   <servlet-name>action</servlet-name>   <servlet-class>     org.apache.struts.action.ActionServlet   </servlet-class>   <init-param>     <param-name>config</param-name>     <param-value>/WEB-INF/struts-config.xml</param-value>   </init-param>   <init-param>     <param-name>debug</param-name>     <param-value>4</param-value>   </init-param>   <load-on-startup>1</load-on-startup> </servlet> 

Using Struts Modules

Struts 1.1 introduced the Struts Modules, an often-overlooked, but sometimes extremely convenient, feature. Struts Modules allow teams of developers to logically segment their Struts applications.

One of the major problems with a Struts 1.0.x application is its dependence on a single struts-config.xml file. While a single configuration file can be handy for small applications, when you're developing a large application this type of monolithic configuration can be both cumbersome and contentious. Because everyone is fighting over this single file, you often step on one another's changes and may run into merge conflicts when checking your changes into version control.

Struts Modules were created with these conflicts in mind. Struts Modules allow a team to logically separate their segment of a single application into the equivalent of a "sub-Web" application, each with its own struts-config.xml file. Although this separation does not resolve all chances of conflict, it does reduce those chances significantly.

Configuring Struts Modules

It is extremely easy to configure a Struts Module. You can do it in a few simple steps. For this example, let's segment an Administrative piece of a Struts application:

  1. Create a directory that describes your new Module. For this example, create a directory named admin/ that will be used as a logical slice containing the application's administrative functionality.

  2. Copy all of the related JSP and View components into this directory.

  3. Create a new struts-config.xml file that will describe the related Struts components of this new segment and copy it to the WEB-INF/ directory of your application. Let's name our sample admin/ module struts-config-admin.xml.

    start sidebar

    In step 3, we are copying the Module's struts-config-admin.xml file into the WEB-INF/ directory of the Web application, not the Module's WEB-INF/ directory. All Modules share the same WEB-INF/ directory, classpath, and web.xml file. They are different only in their subdirectory and their struts-config.xml files.

    end sidebar

  4. In the newly created struts-config-XXX.file, add the prefix of your Module to all of your context-relative resources. An example of this is a <global-forward/>. If it referenced a JSP as userAdmin.jsp, you would need to change this reference to /admin/userAdmin.jsp.

  5. Add a new Servlet <init-param> entry to the web.xml file that describes your new Module:

     <init-param>   <param-name>config/admin</param-name>   <param-value>/WEB-INF/struts-config-admin.xml</param-value> </init-param> 

That's about it. The next time you start your Struts application, your new Module will be available and accessible when you insert the Module's name into the URL (following the Web application name and before the requested resource). This URL shows how you would reference our admin/ application's index.jsp:

  • http://locahost:8080/wroxapp/admin/index.jsp

We see more tips for using Struts Modules in Chapter 21, "Struts Cookbook."



 < Day Day Up > 



Professional Jakarta Struts
Professional Jakarta Struts (Programmer to Programmer)
ISBN: 0764544373
EAN: 2147483647
Year: 2003
Pages: 183

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net