Thanks. That is going to be of great use for me. I imagine that way i can call the same Action class from different jsp pages, and, if desired, each jsp page is going to execute a different method in Action class. Right? The main purpose of this is: I have to know the jsp page I was before going to my Action class. Depending on the jsp I was, i have to "mapping.findForward(whatever)", where "whatever" is the jsp I called the Action from (there are 10 different pages where this Action class can be called).
Thanks very much Ot�vio Augusto On Thu, 8 Jan 2004 00:16:10 -0700 "Richard Hightower" <[EMAIL PROTECTED]> wrote: > Check out > > http://doc.advisor.com/Articles.nsf/nl/13372 > > (I wrote it).... > > snippet below.... > > > the above tutorial covers dispatch action and lookup disptacth action.... > > i am not a fan of lookup dispatch action. > > i like dispatch action. > > (i created my own dispatch action called ButtonNameDispatchAction, which > seemed to work better for our application, certainly easier to setup than > LookupDispatchAction. I also create a MappingParameterDispatchAction, and > sometimes I just use the mapping parameter with an if/else block. > > Rick Hightower > Developer > > Struts/J2EE training -- http://www.arc-mind.com/strutsCourse.htm > > Struts/J2EE consulting -- > http://www.arc-mind.com/consulting.htm#StrutsMentoring > > DispatchAction > > 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: > 1. Create an action handler class that subclasses DispatchAction. > 2. Create a method to represent each logical related action. > 3. 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. > 4. 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 > > > -----Original Message----- > From: Ot�vio Augusto [mailto:[EMAIL PROTECTED] > Sent: Thursday, January 08, 2004 12:01 AM > To: [EMAIL PROTECTED] > Subject: many methods in Action > > > Does anybody have a tutorial/howto on how to have many different tasks > implemented in a single Action class? I mean,many "execute" methods (of > course, different signatures) in the same Action class. > Thanks a lot. > > Ot�vio Augusto > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
