DispatchAction | Professional Jakarta Struts (Programmer to Programmer)

< Day Day Up >

Oftentimes actions seem to be too plentiful and too small. It would be nice to group related actions into one class.

For example, let's say that a group of related actions all work on the same set of objects in the user session (HttpServletSession)—a shopping cart, for example. Another example is a group of actions that are all involved in the same use case. Yet another example is a group of actions that all communicate with the same session facade. Another example, and one that I use often, is grouping all actions involved in CRUD operations on domain objects. (CRUD stands for create, read, update, and delete. Think of an add/edit/delete/listing of products for an online e-commerce store.)

If you can group related actions into one class, you can create helper methods that they all use, thus improving reuse (or at least facilitating it). Also, if these helper methods are only used by these related actions and these actions are in the same class, then the helper methods can be encapsulated (hidden) inside this one class.

The DispatchAction class is used to group related actions into one class. DispatchAction is an abstract class, so you must override it to use it. It extends the Action class.

Rather than having a single execute method, you have a method for each logical action. The DispatchAction dispatches to one of the logical actions represented by the methods. It picks a method to invoke based on an incoming request parameter. The value of the incoming request parameter is the name of the method that the DispatchAction will invoke.

To use the DispatchAction, follow these steps:

Create an action handler class that subclasses DispatchAction.
Create a method to represent each logical related action.
Create an action mapping for this action handler using the parameter attribute to specify the request parameter that carries the name of the method you want to invoke.
Pass the action a request parameter that refers to the method you want to invoke. First, you create an action handler class that subclasses DispatchAction:

 public class UserDispatchAction extends DispatchAction {     ... }

Then, you create a method to represent each logical related action:

 public class UserDispatchAction extends DispatchAction {      public ActionForward remove(           ActionMapping mapping,           ActionForm form,           HttpServletRequest request,           HttpServletResponse response)           throws Exception {                System.out.println("REMOVE USER");                ...                return mapping.findForward("success");      }      public ActionForward save(           ActionMapping mapping,           ActionForm form,           HttpServletRequest request,           HttpServletResponse response)           throws Exception {                System.out.println("SAVE USER");                 ...                return mapping.findForward("success");      } }

Notice these methods have the same signature (other than the method name) of the standard Action.execute method.

The third step is to create an action mapping for this action handler using the parameter attribute to specify the request parameter that carries the name of the method you want to invoke:

            <action                path="/dispatchUserSubmit"                type="action.UserDispatchAction"                parameter="method"                input="/form/userForm.jsp"                name="userForm"                scope="request"                validate="false">                <forward name="success" path="/success.jsp" />            </action>

Based on this code, the DispatchAction that we created uses the value of the request parameter named method to pick the appropriate method to invoke. The parameter attribute specifies the name of the request parameter that is inspected by the DispatchAction.

The final step is to pass the action a request parameter that refers to the method you want to invoke:

 <%@ taglib uri="/WEB-INF/struts-bean.tld" prefix="bean"%> <%@ taglib uri="/WEB-INF/struts-html.tld" prefix="html"%> ...      <html:link action="home">Home</html:link>      <html:form action="/dispatchUserSubmit">                ...           action:            <html:select property="method" size="2">              <html:option value="save">Save</html:option>              <html:option value="remove">Remove</html:option>           </html:select> <br/>           <html:submit/><html:cancel/>      </html:form> ...

This code is simple. If the user selects Remove from the list and clicks the Submit button, then the remove method is invoked. If the user selects Save from the list and clicks the Submit button, then the save method is invoked. Because the method name corresponds to a request parameter, it is submitted to the DispatchAction, which invokes the method with a name corresponding to the value of the method parameter.

A more likely implementation would send a hidden field parameter instead of a drop-down list. (Chapter 12 contains such an example; it performs validation for a wizard-style set of forms.)

If you were going to implement a CRUD operation, you might have methods called create, read, list, update, and delete. Essentially the action that was responsible for the read operation (the R in CRUD) would set a string in request scope (set to update) that could be written back out as the hidden parameter by the JSP. The action that was responsible for creating a new user would set that same string to create. The idea is that the action before the form display always sets up the hidden parameter for the form to submit back to the next action. If there were a listing of users, the listing would have two links that point to this action, with parameters set to delete users and to read/update (edit) users:

 method=delete and method=read&userid=10

< Day Day Up >