You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Michael McGrady <mi...@michaelmcgrady.com> on 2004/09/16 21:44:30 UTC
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
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