ParameterDispatchAction resolves the method directly from the value of the parameter. parameter="add" would look for a method in the user's subclass named 'add'.
Unlike DispatchAction, the various action definitions do not need to share the same attributes. Each action is defined separately with its own path, form, validation etc. For example, you could combine all the CRUD related actions for a business object into a single action class to better organize and encapsulate code, but still be able to validate forms in some actions but not in others. I don't see any technical reason why this couldn't be combined with DispatchAction but it feels like cramming too much in to a single class to me. (There's already a request in Bugzilla to combine LookupDispatchAction with DispatchAction). I prefer that each class do one thing and do it well rather than try to shoehorn several different resolution methods into a single class. Steve > -----Original Message----- > From: Craig R. McClanahan [mailto:[EMAIL PROTECTED] > Sent: August 1, 2003 9:01 AM > To: Struts Developers List; [EMAIL PROTECTED] > Subject: Re: Addition of two new actions > > > > > On Thu, 31 Jul 2003, Steve Raeburn wrote: > > > Date: Thu, 31 Jul 2003 23:10:59 -0700 > > From: Steve Raeburn <[EMAIL PROTECTED]> > > Reply-To: Struts Developers List <[EMAIL PROTECTED]>, > > [EMAIL PROTECTED] > > To: Struts Developers List <[EMAIL PROTECTED]> > > Subject: Addition of two new actions > > > > I'd like to add two new actions to org.apache.struts.actions that I find > > particularly useful. > > > > 1. SuccessAction - A simple action that forwards control to an > ActionFoward > > named "success". > > > > This is a very simple action, but I find it exceptionally useful, > > particularly in the early stages of development when it can act as a > > placeholder for as-yet undeveloped actions. > > > > public ActionForward execute( > > ActionMapping mapping, > > ActionForm form, > > HttpServletRequest request, > > HttpServletResponse response) > > throws Exception { > > > > ActionForward forward = mapping.findForward("success"); > > if (forward == null) { > > String message = > > messages.getMessage("success.required", mapping.getPath()); > > log.error(message); > > throw new ServletException(message); > > } > > return forward; > > } > > > > I agree with others in the thread pointing out that this would be > redundant. > > > 2. ParameterDispatchAction - A DispatchAction that selects a > handler method > > using the value of the ActionMapping parameter. > > > > This is as per the suggestion by Anthony Kay via Bugzilla > > <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17117>, > except I prefer > > the name ParameterDispatchAction to his suggestion of > ConfigDispatchAction > > as I think it's more descriptive of what the class actually > does. Other than > > the name change, I've just tidied up the Javadoc and changed the > > 'unspecified' method to throw an Exception (as in DispatchAction) rather > > than return an Http error code. > > > > If no one has any problems with adding these two, I'll put them > in tomorrow. > > Could you help me understand how this is different from what > DispatchAction already does, or why we couldn't just update DispatchAction > itself to add any additional functionality it represents? > > > > > > > Steve > > Craig > > --------------------------------------------------------------------- > 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]
