On Fri, 1 Aug 2003, Steve Raeburn wrote:
> Date: Fri, 1 Aug 2003 10:01:35 -0700 > From: Steve Raeburn <[EMAIL PROTECTED]> > Reply-To: Struts Developers List <[EMAIL PROTECTED]>, > [EMAIL PROTECTED] > To: Struts Developers List <[EMAIL PROTECTED]> > Subject: RE: Addition of two new actions > > 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. > So, what you really want is LookupDispatchAction without requiring the developer to create the map-related methods? I think you already get the abililty to combine CRUD related actions and things like that. If so, then implementing a default getKeyMethodMap() in LookupDispatchAction might accomplish the same goal, without requiring another action. Such a default implementation could examine the current LookupDispatchAction subclass and create the mapping information automatically. Don't get me wrong ... I like the idea behind what you're proposing. I just think we might already have it (with the potential to improve ease of use by not forcing people to implement getKeyMethodMap() for a common use case). > Steve Craig > > > -----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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
