You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Hubert Rabago <hr...@gmail.com> on 2004/09/16 21:23:13 UTC
RE: DispatchAction (was: [Apache Struts Wiki] Updated: StrutsCatalogSimpleDispatchAction)
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, dev@struts.apache.org
<de...@struts.apache.org> wrote:
> Date: 2004-09-16T11:05:45
> Editor: NiallPemberton <ni...@apache.org>
> 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: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: DispatchAction
Posted by Michael McGrady <mi...@michaelmcgrady.com>.
I probably should have noted that SimpleDispatchAction is a complete
substitute for and works in all cases for whatever we do with
DispatchAction, LookupDispatchAction, and MappingDispatchAction. That
might be another reason for making it the superclass, if you really want
to connect them.
Maybe it should be in another lineage entirely?
I probably should not have named it "SimpleDispatchAction". Again, the
only logic in common is the reflection that calls the methods, which, of
course, is not really "logic" at all.
The real "meat" of DispatchAction is that it allows you to get "update"
from value of the request parameter (requestParam = update) via the
ActionMapping parameter. This is not, in my view, a "feature" but a
problem. The real "meat" of SimpleDispatchAction is that it gets the
name of the request parameter (update.x=) and leaves the value of the
request parameter and the parameter property of the ActionMapping free
for other service entirely.
Michael McGrady
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: DispatchAction
Posted by Michael McGrady <mi...@michaelmcgrady.com>.
Niall Pemberton wrote:
>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.
>
Thatt "slightly different mechanism" changes pretty much completely how
you can relate to the view. _/*You have to remember that these two
classes are obtaining the method name from different places*/_.
Remember too that SimpleDispatchAction does not merely replace
DispatchAction, it replaces DispatchAction, LookupDispatchAction and
MappedDispatchAction. That should show that, while it may (and does)
look like a simple change (and is a simple change) the results are
radically different because of how it relates to the view. For example:
With SimpleDispatchAction, for /any /number of methods, you might have a
struts-config.xml that looks like:
| <action path="/subscription"
type="org.example.SubscriptionAction">
</action>|
With MappingDispatchAction, for a create, edit, save, delete, and list
set of methods, you would have to have the following:
| <action path="/createSubscription"
type="org.example.SubscriptionAction"
parameter="create">
<forward name="success" path="/editSubscription.jsp"/>
</action>
<action path="/editSubscription"
type="org.example.SubscriptionAction"
parameter="edit">
<forward name="success" path="/editSubscription.jsp"/>
</action>
<action path="/saveSubscription"
type="org.example.SubscriptionAction"
parameter="save"
name="subscriptionForm"
validate="true"
input="/editSubscription.jsp"
scope="request">
<forward name="success" path="/savedSubscription.jsp"/>
</action>
<action path="/deleteSubscription"
type="org.example.SubscriptionAction"
name="subscriptionForm"
scope="request"
input="/subscription.jsp"
parameter="delete">
<forward name="success" path="/deletedSubscription.jsp"/>
</action>
<action path="/listSubscriptions"
type="org.example.SubscriptionAction"
parameter="list">
<forward name="success" path="/subscriptionList.jsp"/>
</action>
|
Additionally, what will occur on the page will be completely different.
That does not mean a link won't be a link and a file browse won't be a
file browse, etc. What it means is that the view code will be broken.
I am a pretty good coder and sometimes not the best communicator on
these things because I tend to come from a different angle, being
self-trained. Rick Reumann is changing some things to use this instead
of MappingDispatchAction, I think. Maybe he can be helpful to you on this.
Michael McGrady
||||| |
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: DispatchAction
Posted by Niall Pemberton <ni...@blueyonder.co.uk>.
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" <mi...@michaelmcgrady.com>
To: "Struts Developers List" <de...@struts.apache.org>
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, dev@struts.apache.org
> ><de...@struts.apache.org> wrote:
> >
> >
> >> Date: 2004-09-16T11:05:45
> >> Editor: NiallPemberton <ni...@apache.org>
> >> 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: dev-unsubscribe@struts.apache.org
> >>For additional commands, e-mail: dev-help@struts.apache.org
> >>
> >>
> >>
> >>
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >For additional commands, e-mail: dev-help@struts.apache.org
> >
> >
> >
> >
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: DispatchAction
Posted by Michael McGrady <mi...@michaelmcgrady.com>.
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, dev@struts.apache.org
><de...@struts.apache.org> wrote:
>
>
>> Date: 2004-09-16T11:05:45
>> Editor: NiallPemberton <ni...@apache.org>
>> 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: dev-unsubscribe@struts.apache.org
>>For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>>
>>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>For additional commands, e-mail: dev-help@struts.apache.org
>
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: DispatchAction
Posted by Michael McGrady <mi...@michaelmcgrady.com>.
Michael McGrady wrote:
> Hubert Rabago wrote:
>
>> Yes, that's the general idea. Like I said, I haven't looked at it
>> closely yet to see if it's doable for the existing *DispatchAction
>> flavors. *If* it can be done (some methods just can't be moed that
>> easily), then the functionality becomes available to Action subclasses
>> that don't extend one of the DispatchAction classes.
>>
>
> I flopped together a quick class for testing this with
> SimpleDispatchAction and it works fine. I've tested it.
>
\Oops, forgot to toss it in:
package com.crackwillow.struts.util.dispatch;
import java.lang.reflect.InvocationTargetException;
import java.lang.reflect.Method;
import java.util.Enumeration;
import java.util.HashMap;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
import org.apache.struts.action.Action;
import org.apache.struts.action.ActionForm;
import org.apache.struts.action.ActionForward;
import org.apache.struts.action.ActionMapping;
import org.apache.struts.util.MessageResources;
a
import com.crackwillow.log.StdOut;
public class DispatchUtil {
protected static Log log =
LogFactory.getLog(DispatchUtil.class);
protected static MessageResources messages =
MessageResources.getMessageResources
("org.apache.struts.actions.LocalStrings");
protected HashMap methods = new HashMap();
protected Class[] types = { ActionMapping.class,
ActionForm.class,
HttpServletRequest.class,
HttpServletResponse.class };
public ActionForward dispatch(Action action,
ActionMapping mapping,
ActionForm
form,
HttpServletRequest request,
HttpServletResponse response)
throws Exception {
Class clazz = action.getClass();
String name = getMethodName(request,mapping);
if ("execute".equals(name) || "perform".equals(name)){
// Prevent recursive calls
String message = messages.getMessage("dispatch.recursive",
mapping.getPath());
log.error(message);
throw new ServletException(message);
}
return dispatchMethod(action,clazz,mapping, form, request, response,
name);
}
protected ActionForward dispatchMethod(Action action,
Class clazz,
ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response,
String name)
throws Exception {
if (name == null) {
return this.unspecified(mapping, form, request, response);
}
Method method = null;
try {
method = getMethod(clazz,name);
} catch(NoSuchMethodException nsme) {
String message = messages.getMessage("dispatch.method",
mapping.getPath(), name);
log.error(message, nsme);
throw nsme;
}
ActionForward forward = null;
try {
Object args[] = {mapping, form, request, response};
forward = (ActionForward) method.invoke(action, args);
} catch(ClassCastException cce) {
String message = messages.getMessage("dispatch.return",
mapping.getPath(), name);
log.error(message, cce);
throw cce;
} catch(IllegalAccessException iae) {
String message = messages.getMessage("dispatch.error",
mapping.getPath(), name);
log.error(message, iae);
throw iae;
} catch(InvocationTargetException ite) {
Throwable t = ite.getTargetException();
if (t instanceof Exception) {
throw ((Exception) t);
} else {
String message = messages.getMessage("dispatch.error",
mapping.getPath(), name);
log.error(message, ite);
throw new ServletException(t);
}
}
return (forward);
}
protected static String getMethodName(HttpServletRequest request,
ActionMapping mapping) {
String methodName = null;
String buttonValue = null;
String parameter = mapping.getParameter();
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;
}
protected Method getMethod(Class clazz,String name)
throws NoSuchMethodException {
synchronized(methods) {
Method method = (Method) methods.get(name);
if (method == null) {
method = clazz.getMethod(name, types);
methods.put(name, method);
}
return (method);
}
}
protected ActionForward unspecified(ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response)
throws Exception {
String message = messages.getMessage( "dispatch.parameter",
mapping.getPath(), getMethodName(request,mapping));
log.error(message);
throw new ServletException(message);
}
protected ActionForward cancelled(ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response)
throws Exception {
return null;
}
}
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: DispatchAction
Posted by Michael McGrady <mi...@michaelmcgrady.com>.
Hubert Rabago wrote:
>Yes, that's the general idea. Like I said, I haven't looked at it
>closely yet to see if it's doable for the existing *DispatchAction
>flavors. *If* it can be done (some methods just can't be moed that
>easily), then the functionality becomes available to Action subclasses
>that don't extend one of the DispatchAction classes.
>
I flopped together a quick class for testing this with
SimpleDispatchAction and it works fine. I've tested it.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: DispatchAction
Posted by Hubert Rabago <hr...@gmail.com>.
Yes, that's the general idea. Like I said, I haven't looked at it
closely yet to see if it's doable for the existing *DispatchAction
flavors. *If* it can be done (some methods just can't be moed that
easily), then the functionality becomes available to Action subclasses
that don't extend one of the DispatchAction classes.
On Thu, 16 Sep 2004 15:07:36 -0700, Michael McGrady
<mi...@michaelmcgrady.com> wrote:
>
>
> Hubert Rabago wrote:
>
> > public ActionForward execute(_usual_params) {
> > RequestUtils.dispatch(this, _usual_params);
> > }
> >
> This will work fine for SimpleDispatchAction, in fact I LOVE IT and I am
> going to do it, if you don't, but this would not replace DispatchAction,
> LookupDispatchAction or MappingDispatchAction, and there probably is a
> lot of code out there with those actions. You would have to provide the
> following four options.
>
> RequestUtils.dispatch(this,_usual_params);
> RequestUtils.lookupDispatch(this,_usual_params);
> RequestUtils.mappingDispatch(this,_usual_params);
> RequestUtils.simpleDispatch(this,_usual_params);
>
> I want to emphasize, however, that
> RequestUtils.simpleDispatch(this,_usual_params) will do everything that
> the others do and do what they do more simply, but it is based on
> different data.
>
> Michael
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: DispatchAction
Posted by Michael McGrady <mi...@michaelmcgrady.com>.
Hubert Rabago wrote:
> public ActionForward execute(_usual_params) {
> RequestUtils.dispatch(this, _usual_params);
> }
>
This will work fine for SimpleDispatchAction, in fact I LOVE IT and I am
going to do it, if you don't, but this would not replace DispatchAction,
LookupDispatchAction or MappingDispatchAction, and there probably is a
lot of code out there with those actions. You would have to provide the
following four options.
RequestUtils.dispatch(this,_usual_params);
RequestUtils.lookupDispatch(this,_usual_params);
RequestUtils.mappingDispatch(this,_usual_params);
RequestUtils.simpleDispatch(this,_usual_params);
I want to emphasize, however, that
RequestUtils.simpleDispatch(this,_usual_params) will do everything that
the others do and do what they do more simply, but it is based on
different data.
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: DispatchAction
Posted by Michael McGrady <mi...@michaelmcgrady.com>.
Hubert Rabago wrote:
>I haven't had a chance to look into the latest DispatchAction yet, but
>if it's already in there, I wouldn't be surprised.
>
This cannot be. I am not sure you two see what this does. I know you
two are sharp cookies, but you might be looking at the results and
seeing they are the same and missing that the data from which the
results are obtained is different. So, this cannot be and the
suggestion shows that you are missing what is happening, I think. The
value that is mined, retrieved, obtained in SimpleDispatchAction is not
even the same value as that obtined with DispatchAction. This is not
merely an efficiency issue but a change in how the dispatching relates
to the view and, so, to the ActionMapping.
Michael McGrady
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: DispatchAction
Posted by Michael McGrady <mi...@michaelmcgrady.com>.
Hubert Rabago wrote:
>What I had in mind was moving the "find which Action method to call
>then call it" logic to a utility class, so that if I needed that
>functionality, I could use it without having to inherit DispatchAction
>or one of its subclasses. This way, I wouldn't have to choose between
>having a BaseAction that's used by all the Actions in my application
>and one of the DispatchAction flavors.
>
I did this quite a while ago with
public class ImageTagUtil {
public static String getName(HttpServletRequest request) {
String command = null;
String buttonValue = null;
Enumeration enum = request.getParameterNames();
while(enum.hasMoreElements()) {
buttonValue = (String)enum.nextElement();
if(buttonValue.endsWith(".x")) {
command = buttonValue.substring(0,buttonValue.indexOf('.'));
}
}
return command;
}
}
at
http://wiki.apache.org/struts/StrutsCatalogMultipleImageTagsSimplified
. I just employed put it in SimpleDispatchAction to get the
reflection. If you do this with utils on the side, which seems like a
good idea but not good enough to bloat Struts with to me, then you have
to understand that this will not work for code that has used
DispatchAction, LookupDispatchAction or MappingDIspatchAction, because
those classes use different data.
Michael McGrady
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: DispatchAction
Posted by Michael McGrady <mi...@michaelmcgrady.com>.
Actually, Hubert,
With SimpleDispatchAction this makes a lot of sense. I would really go
for this and think I will work on that too. I don't think it makes a
lot of sense for the present actions, however, because they are so
wedded to the ActionMapping. SimpleDispatchAction allows that but the
present actions require it.
I definitely, however, think that this would be vastly preferable to the
SimpleDispatchAction code and would be very useful even without a
MySuperAmazingBaseAction, which probably is Action? LOL ;-) This
might even be something, as a util, that I would see as not a "bloat".
Michael McGrady
Hubert Rabago wrote:
>What I had in mind was moving the "find which Action method to call
>then call it" logic to a utility class, so that if I needed that
>functionality, I could use it without having to inherit DispatchAction
>or one of its subclasses. This way, I wouldn't have to choose between
>having a BaseAction that's used by all the Actions in my application
>and one of the DispatchAction flavors.
>
>Like this:
>
>public class MyDispatchAction extends MySuperAmazingBaseAction {
> public ActionForward execute(_usual_params) {
> RequestUtils.dispatch(this, _usual_params);
> }
>
> public ActionForward add(_usual_params) { }
>
> public ActionForward edit(_usual_params) { }
>
> public ActionForward save(_usual_params) { }
>}
>
>Hubert
>
>On Thu, 16 Sep 2004 22:07:30 +0100, Niall Pemberton
><ni...@blueyonder.co.uk> wrote:
>
>
>>Hubert,
>>
>>Is this what has already happened in DispatchAction with the getMethodName()
>>method that has been added since Struts 1.2.0?
>>
>>Maybe I've mis-understood what you're saying.
>>
>>Niall
>>
>>
>>
>>
>>----- Original Message -----
>>From: "Hubert Rabago" <hr...@gmail.com>
>>To: "Struts Developers List" <de...@struts.apache.org>
>>Sent: Thursday, September 16, 2004 8:23 PM
>>Subject: RE: DispatchAction (was: [Apache Struts Wiki] Updated:
>>StrutsCatalogSimpleDispatchAction)
>>
>>
>>
>>>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, dev@struts.apache.org
>>><de...@struts.apache.org> wrote:
>>>
>>>
>>>> Date: 2004-09-16T11:05:45
>>>> Editor: NiallPemberton <ni...@apache.org>
>>>> 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: dev-unsubscribe@struts.apache.org
>>>>For additional commands, e-mail: dev-help@struts.apache.org
>>>>
>>>>
>>>>
>>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>For additional commands, e-mail: dev-help@struts.apache.org
>>>
>>>
>>>
>>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>>
>>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>For additional commands, e-mail: dev-help@struts.apache.org
>
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: DispatchAction (was: [Apache Struts Wiki] Updated: StrutsCatalogSimpleDispatchAction)
Posted by Hubert Rabago <hr...@gmail.com>.
I haven't had a chance to look into the latest DispatchAction yet, but
if it's already in there, I wouldn't be surprised. I'll take a look
later.
What I had in mind was moving the "find which Action method to call
then call it" logic to a utility class, so that if I needed that
functionality, I could use it without having to inherit DispatchAction
or one of its subclasses. This way, I wouldn't have to choose between
having a BaseAction that's used by all the Actions in my application
and one of the DispatchAction flavors.
Like this:
public class MyDispatchAction extends MySuperAmazingBaseAction {
public ActionForward execute(_usual_params) {
RequestUtils.dispatch(this, _usual_params);
}
public ActionForward add(_usual_params) { }
public ActionForward edit(_usual_params) { }
public ActionForward save(_usual_params) { }
}
Hubert
On Thu, 16 Sep 2004 22:07:30 +0100, Niall Pemberton
<ni...@blueyonder.co.uk> wrote:
> Hubert,
>
> Is this what has already happened in DispatchAction with the getMethodName()
> method that has been added since Struts 1.2.0?
>
> Maybe I've mis-understood what you're saying.
>
> Niall
>
>
>
>
> ----- Original Message -----
> From: "Hubert Rabago" <hr...@gmail.com>
> To: "Struts Developers List" <de...@struts.apache.org>
> Sent: Thursday, September 16, 2004 8:23 PM
> Subject: RE: DispatchAction (was: [Apache Struts Wiki] Updated:
> StrutsCatalogSimpleDispatchAction)
>
> > 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, dev@struts.apache.org
> > <de...@struts.apache.org> wrote:
> > > Date: 2004-09-16T11:05:45
> > > Editor: NiallPemberton <ni...@apache.org>
> > > 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: dev-unsubscribe@struts.apache.org
> > > For additional commands, e-mail: dev-help@struts.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
> >
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: DispatchAction
Posted by Michael McGrady <mi...@michaelmcgrady.com>.
Niall Pemberton wrote:
>Hubert,
>
>Is this what has already happened in DispatchAction with the getMethodName()
>method that has been added since Struts 1.2.0?
>
>Maybe I've mis-understood what you're saying.
>
>Niall
>
>
No, that cannot be true, Niall, because eveyrone's code would break.
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: DispatchAction (was: [Apache Struts Wiki] Updated: StrutsCatalogSimpleDispatchAction)
Posted by Niall Pemberton <ni...@blueyonder.co.uk>.
Hubert,
Is this what has already happened in DispatchAction with the getMethodName()
method that has been added since Struts 1.2.0?
Maybe I've mis-understood what you're saying.
Niall
----- Original Message -----
From: "Hubert Rabago" <hr...@gmail.com>
To: "Struts Developers List" <de...@struts.apache.org>
Sent: Thursday, September 16, 2004 8:23 PM
Subject: RE: DispatchAction (was: [Apache Struts Wiki] Updated:
StrutsCatalogSimpleDispatchAction)
> 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, dev@struts.apache.org
> <de...@struts.apache.org> wrote:
> > Date: 2004-09-16T11:05:45
> > Editor: NiallPemberton <ni...@apache.org>
> > 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: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org