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]
