I don't see anything radically different in SimpleDispatchAction to the other DispatchAction flavours - it just uses a slightly different mechanim for determining the method name to execute and it doesn't throw an exception if the "parameter" is null.
Looking at it, it seemed to me that factoring out retrieving the parameter in DispatchAction into a separate method would mean that your SimpleDispatchAction could re-use the bulk of the DispatchAction code that it was duplicating and just provide the slight different "flavour" of method name determination that you are keen on by overriding the getMethodName() method - making SimpleDispatchAction much simpler :-) Personally I don't use DispatchAction or any of its flavours at all and for me SimpleDispatchAction doesn't seem to provide that much difference in behaviour to make me think it would be worth adding into Struts - but if the getParameter() refactoring of DispatchAction is helpful and makes extending its behaviour easier then I'd be willing to do that. To be honest Michael I'm confused by you saying SimpleDispatchAction is *radically* different - I just don't see it. Maybe if you could point out the radical differences in simple enough sentances for me understand then I might get it? Niall ----- Original Message ----- From: "Michael McGrady" <[EMAIL PROTECTED]> To: "Struts Developers List" <[EMAIL PROTECTED]> Sent: Thursday, September 16, 2004 8:44 PM Subject: Re: DispatchAction > What SimpleDispatchAction does not duplicate is the logic of > DispatchAction vis-a-vis the view in the MVC. There is no need at all > for a getParameter() method in SimpleDispatchAction. The logic if very > different. In essence, DispatchAction substitutes the parameter of > ActionMapping for the name in submit and adds the value of name to the > parameter in ActionMapping. SimpleDispatchAction avoids all of this by > strip mining the name in submit, image, file, link, etc. and leaving the > value in the request parameter and the value of the parameter in the > MappingAction to be whatever you want. > > I think myself that some of these classes are just good ideas and really > should not be in the Struts application. If you start putting these in > you will just, I think, bloat Struts unnecessarily. If someone wants > these, they should be available on the wiki or whatever. However, if > you think they should go into the Struts application itself, then I > don't think the suggestion really works. You simply have way too much > baggage in DispatchAction for SimpleDispatchAction. If you wanted to > refactor by reversing the situation and making SimpleDispatchAction the > superclass, that, I think, works better. But the actual use of these > two classes is so radically different I actually think separating them > entirely would be the best bet. The only thing they have in comom is > the use of the reflection really. That is not much in common. They do > meet similar needs but in radically different ways. > > Michael McGrady > > Hubert Rabago wrote: > > >I was actually thinking of playing around with this idea, so that the > >way the method is determined is refactored out, similar to how you > >(Niall) changed ValidatorActionForm. > > > >Specifically, I'm interested in figuring out if we can refactor it in > >such a way that it becomes useful to other Action hierarchies. One of > >the issues with using an app-specific base class is that they lose the > >functionality provided by the Action subclasses that comes with > >Struts. If we can move this code outside of the *DispatchAction > >classes, app-specific base classes can take advantage of these > >features as well. > > > >Hubert > > > >On Thu, 16 Sep 2004 18:05:46 -0000, [EMAIL PROTECTED] > ><[EMAIL PROTECTED]> wrote: > > > > > >> Date: 2004-09-16T11:05:45 > >> Editor: NiallPemberton <[EMAIL PROTECTED]> > >> Wiki: Apache Struts Wiki > >> Page: StrutsCatalogSimpleDispatchAction > >> URL: http://wiki.apache.org/struts/StrutsCatalogSimpleDispatchAction > >> > >> no comment > >> > >>Change Log: > >> > >>-------------------------------------------------------------------------- ---- > >>@@ -179,5 +179,47 @@ > >> > >>'''Michael !McGrady''' > >> > >>+---- > >> > >>+Seems to me that most of the SimpleDispatchAction duplicates whats already in the DispatchAction class. If we re-factored DispatchAction so that the parameter retrieval was moved into a new getParameter() method then all that would be needed to achieve what you want is a flavour that overrides the getParameter()/getMethodName() methods. > >>+ > >>+Something along the lines of ... > >>+ > >>+{{{ > >>+public abstract class SimpleDispatchAction extends DispatchAction { > >>+ > >>+ protected String getParameter(ActionMapping mapping, > >>+ ActionForm form, > >>+ HttpServletRequest request, > >>+ HttpServletResponse response) { > >>+ > >>+ return mapping.getParameter(); > >>+ > >>+ } > >>+ > >>+ protected String getMethodName(ActionMapping mapping, > >>+ ActionForm form, > >>+ HttpServletRequest request, > >>+ HttpServletResponse response, > >>+ String parameter) { > >>+ > >>+ if((parameter != null) && (parameter.endsWith(".x"))) { > >>+ methodName = parameter.substring(0,parameter.indexOf('.')); > >>+ } else { > >>+ Enumeration enum = request.getParameterNames(); > >>+ while(enum.hasMoreElements()) { > >>+ buttonValue = (String)enum.nextElement(); > >>+ if(buttonValue.endsWith(".x")) { > >>+ methodName = buttonValue.substring(0,buttonValue.indexOf(".x")); > >>+ } > >>+ } > >>+ } > >>+ return methodName; > >>+ } > >>+ > >>+} > >>+ > >>+}}} > >>+ > >>+'''Niall Pemberton''' > >> > >>--------------------------------------------------------------------- > >>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] > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
