You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Brandon Goodin <ma...@phase.ws> on 2003/05/14 17:30:22 UTC
[FLAME]Chaining Actions - Best Practise
Actually, this is not a flame :-)) I just thought the topic is always hot
so...
Action chaining in regards to forwarding from one action to another via the
request is a bad practice. But, it does NOT infer that you are placing
business logic into you Action class. On the contrary having actions that
need to prepare data for a page is right in line with the Model2. If you are
making decisions about which Action to forward to within the body of you
Action, that would not be appropriate. In that case you are doing what David
said. However, if you are merely preparing data for a page and not making
Action forwarding decision in the calling Action then I think that the COR
pattern is appropriate. In other words, if you have a static set pipeline of
actions that prepare data for a page and it is easier to reuse actions to
populate a form than write a new one then... do it. It makes sense in the
realm of reuse and configurable flexibility. Besides with DynaActionForms it
is much more possible to create some Actions that can use the same form.
This makes the possibility using a "COR" pattern much more possible and the
reuse of Actions much more possible.
I have set up a sourceforge project with Karl Baum and will hopefully be
adding some funcitonality to his code soon. Here are the two links to his
code. It is a good pattern.
http://www.strutschaining.org
Sourceforge has yet to be set up... but here are the links:
http://strutschaining.sourceforge.net/
http://sourceforge.net/projects/strutschaining/
Brandon Goodin
-----Original Message-----
From: David Graham [mailto:dgraham1980@hotmail.com]
Sent: Wednesday, May 14, 2003 9:09 AM
To: struts-user@jakarta.apache.org
Subject: Re: Chaining Actions - Best Practise
Chaining actions is generally considered a bad practice and usually
indicates that the action is performing too much logic. If you put your
business logic into a separate class you can reuse it in any action that
needs it instead of chaining them. For example, you could have a
CreditCardProcessor.makePayment() method that any action could call.
David
>We have two or three actions that are meant to do some generic work and
>then forward to more specific actions upon success. For instance, one
>action makes credit card payments and can be used with other actions.
>
>I noticed something that happens in this kind of situation.
>
>Lets say that the first action has an associated form bean and
>validate="true". The request is delegated to the ActionServlet, the action
>servlet calls reset on the form, populates the form properties, then
>validates. Upon successful validation the action does a bit of work and
>then forwards to the 2nd action.
>
>The 2nd action also has the same form bean associated with it. I noticed
>that the ActionServlet again calls reset on the form, populates the form
>parameters and then passes the form to the action. I guess this is the
>desired behavior and don't think there is a bug in struts.
>
>The two issues I found are:
>
>1) It does seem unnecessary to reset/populate the form after it has already
>been done once. What if I chained 5 actions. That would be a lot of
>processing power to reset/populate the form 5 times.
>
>2) I only noticed that this happens because we have one action that sets a
>property one way during the work and then forwards to the 2nd action, but
>then when the 2nd action gets the form, the property has been reset back to
>the state of the request parameter. We had to workaround this by not
>associating the form with the action and then manually looking it up from
>the request object.
>
>I'd like to know if anyone has experienced a similar type of situation and
>what they did to make things work the most strutsy way.
>
>Comments appreciated
>Thanks
>Dennis
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: struts-user-help@jakarta.apache.org
>
_________________________________________________________________
Add photos to your messages with MSN 8. Get 2 months FREE*.
http://join.msn.com/?page=features/featuredemail
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
RE: [FLAME]Chaining Actions - Best Practise
Posted by Brandon Goodin <ma...@phase.ws>.
I am helping Karl with this project. I have set up a sourceforge project and
I still need to get the CVS setup.
But, a few features I will be adding to better support the Struts Chaining
will be Forward Aliasing and moving the initialization to a PlugIn of the
struts-config.
Basically, the main ChainAction is the one that handles the real forwarding.
In the chain configuration any actions in the chain will need to alias their
forwards so that they can report a unique forward back to the ChainAction.
This is in the case where actions in the chain have the same forward names.
When a forward is received by the ChainAction it will determine according to
the alias where to forward the request. So, all real forwarding is handled
by the ChainAction itself. Also, their is a need to identify which forward
means "call the next action in the chain". This will be done by defining a
continue attribute in the chain configuration (continue="success"). So, when
the ChainAction receives a forward that tells it to continue processing the
pipeline it will not perform an actual forward via RequestDispatcher or
response.redirect() it will merely call the execute signature of the next
action.
Forms could be a problem here too. Some patches I have submitted to the
Struts project introduce the use of the ListUtils.lazyList into the
DynaActionForm and a WrapperDynaActionForm into the mix. the lazyList will
allow for a collection in a DynaActionForm to be initialized and grow beyond
it's index when requested. The WrapperDynaActionForm allows you to wrap a
normal ActionForm with the accessing capabilities of the DynaActionForm.
This allows you to write an action that will accept both a DynaActionForm
and a hard coded ActionForm and access it's properties via the DynaBean
constructs get(String name) set(String name, Object value). So, it allows
for actions to be made reusable when they are standalone or in a chain.
Also, when using the DynaActionForm exclusivley it allows for easy
configuration when the chain is has an action added to it or removed from
it. You can easily add or remove properties from the DynaActionForm
configuration when their is a need and restart without compiling an all new
ActionForm for that specific chain.
Anyways, any added features and suggestions would be appreciated.
BTW I'm sure we aren't stepping on Craig's toes. If he has an idea he should
put his .02 in. Otherwise, why reinvent the wheel. We could take this same
logic and incorporate it into the Struts base. But,I think it would just
complicate the struts configuration. I see this as an Action level thing and
better handled in it's own config.
Brandon Goodin
-----Original Message-----
From: Peter A. Pilgrim [mailto:peterp@xenonsoft.demon.co.uk]
Sent: Sunday, May 18, 2003 6:38 AM
To: Struts Users Mailing List
Subject: Re: [FLAME]Chaining Actions - Best Practise
Dennis Muhlestein wrote:
> I agree here. We define the mapping to forward to in the struts config
> file. The whole reason we did this is because we wanted a multipage
> controller that we can use in about 5 different situations where we have
> multi page forms. (YES, we looked at strust-wizard. It doesn't work
> with DynaActionForms and especially not DynaValidatorForms which we are
> using almost exclusively).
>
> The MultiPage controller we have written works great, it just has a
> couple quirks as mentioned in my original post.
>
Action Chaining is a more or less the chain of responsibility algorithm
and the way you guys have written the code in strutschaining.org
seems to be right a long the lines. Processor pipelines.
There seems to be a requirement for a sort of UNIX command line pipeline
equivalent for some people. I see a need for some of modular scheme,
in the following instances.
1) Single sign-on
2) Modular web components (Struts Action and Struts Action Form )
3) Intra web application communication
4) Intra Struts modules communication
5) Extreme XML configuration
The only problem with Struts Action chaining are
1) the time of populating the action form has to been determined.
2) specifying final RequestDispatcher operation
3) Breaking out of an action chain (processor line)
4) Treading on Craig's toes. He might have a different design.
>>>>>>>>>>
> David's response:
> "Chaining actions is generally considered a bad practice and usually
> indicates that the action is performing too much logic."
> <<<<<<<<<<
>
> I tend to think just the opposite. We had a big action for our
> registration that delegated which page to go do and all that. Now, we
> stuck the multipage action in front of it and the register action only
> deals with registering the user. I tend to think before we had the
> multipage action, the register action was performing too much logic.
>
--
Peter Pilgrim
__ _____ _____ _____
/ //__ // ___// ___/ + Serverside Java
/ /___/ // /__ / /__ + Struts
/ // ___// ___// ___/ + Expresso Committer
__/ // /__ / /__ / /__ + Independent Contractor
/___//____//____//____/ + Intrinsic Motivation
On Line Resume
||
\\===> `` http://www.xenonsoft.demon.co.uk/no-it-striker.html ''
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: [FLAME]Chaining Actions - Best Practise
Posted by "Peter A. Pilgrim" <pe...@xenonsoft.demon.co.uk>.
Dennis Muhlestein wrote:
> I agree here. We define the mapping to forward to in the struts config
> file. The whole reason we did this is because we wanted a multipage
> controller that we can use in about 5 different situations where we have
> multi page forms. (YES, we looked at strust-wizard. It doesn't work
> with DynaActionForms and especially not DynaValidatorForms which we are
> using almost exclusively).
>
> The MultiPage controller we have written works great, it just has a
> couple quirks as mentioned in my original post.
>
Action Chaining is a more or less the chain of responsibility algorithm
and the way you guys have written the code in strutschaining.org
seems to be right a long the lines. Processor pipelines.
There seems to be a requirement for a sort of UNIX command line pipeline
equivalent for some people. I see a need for some of modular scheme,
in the following instances.
1) Single sign-on
2) Modular web components (Struts Action and Struts Action Form )
3) Intra web application communication
4) Intra Struts modules communication
5) Extreme XML configuration
The only problem with Struts Action chaining are
1) the time of populating the action form has to been determined.
2) specifying final RequestDispatcher operation
3) Breaking out of an action chain (processor line)
4) Treading on Craig's toes. He might have a different design.
>>>>>>>>>>
> David's response:
> "Chaining actions is generally considered a bad practice and usually
> indicates that the action is performing too much logic."
> <<<<<<<<<<
>
> I tend to think just the opposite. We had a big action for our
> registration that delegated which page to go do and all that. Now, we
> stuck the multipage action in front of it and the register action only
> deals with registering the user. I tend to think before we had the
> multipage action, the register action was performing too much logic.
>
--
Peter Pilgrim
__ _____ _____ _____
/ //__ // ___// ___/ + Serverside Java
/ /___/ // /__ / /__ + Struts
/ // ___// ___// ___/ + Expresso Committer
__/ // /__ / /__ / /__ + Independent Contractor
/___//____//____//____/ + Intrinsic Motivation
On Line Resume
||
\\===> `` http://www.xenonsoft.demon.co.uk/no-it-striker.html ''
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: [FLAME]Chaining Actions - Best Practise
Posted by Dennis Muhlestein <de...@zserve.com>.
I agree here. We define the mapping to forward to in the struts config
file. The whole reason we did this is because we wanted a multipage
controller that we can use in about 5 different situations where we have
multi page forms. (YES, we looked at strust-wizard. It doesn't work
with DynaActionForms and especially not DynaValidatorForms which we are
using almost exclusively).
The MultiPage controller we have written works great, it just has a
couple quirks as mentioned in my original post.
>>>>>>>>>
David's response:
"Chaining actions is generally considered a bad practice and usually
indicates that the action is performing too much logic."
<<<<<<<<<<
I tend to think just the opposite. We had a big action for our
registration that delegated which page to go do and all that. Now, we
stuck the multipage action in front of it and the register action only
deals with registering the user. I tend to think before we had the
multipage action, the register action was performing too much logic.
Dennis
Brandon Goodin wrote:
>Actually, this is not a flame :-)) I just thought the topic is always hot
>so...
>
>Action chaining in regards to forwarding from one action to another via the
>request is a bad practice. But, it does NOT infer that you are placing
>business logic into you Action class. On the contrary having actions that
>need to prepare data for a page is right in line with the Model2. If you are
>making decisions about which Action to forward to within the body of you
>Action, that would not be appropriate. In that case you are doing what David
>said. However, if you are merely preparing data for a page and not making
>Action forwarding decision in the calling Action then I think that the COR
>pattern is appropriate. In other words, if you have a static set pipeline of
>actions that prepare data for a page and it is easier to reuse actions to
>populate a form than write a new one then... do it. It makes sense in the
>realm of reuse and configurable flexibility. Besides with DynaActionForms it
>is much more possible to create some Actions that can use the same form.
>This makes the possibility using a "COR" pattern much more possible and the
>reuse of Actions much more possible.
>
>I have set up a sourceforge project with Karl Baum and will hopefully be
>adding some funcitonality to his code soon. Here are the two links to his
>code. It is a good pattern.
>
>http://www.strutschaining.org
>
>Sourceforge has yet to be set up... but here are the links:
>
>http://strutschaining.sourceforge.net/
>http://sourceforge.net/projects/strutschaining/
>
>Brandon Goodin
>
>-----Original Message-----
>From: David Graham [mailto:dgraham1980@hotmail.com]
>Sent: Wednesday, May 14, 2003 9:09 AM
>To: struts-user@jakarta.apache.org
>Subject: Re: Chaining Actions - Best Practise
>
>
>Chaining actions is generally considered a bad practice and usually
>indicates that the action is performing too much logic. If you put your
>business logic into a separate class you can reuse it in any action that
>needs it instead of chaining them. For example, you could have a
>CreditCardProcessor.makePayment() method that any action could call.
>
>David
>
>
>
>
>>We have two or three actions that are meant to do some generic work and
>>then forward to more specific actions upon success. For instance, one
>>action makes credit card payments and can be used with other actions.
>>
>>I noticed something that happens in this kind of situation.
>>
>>Lets say that the first action has an associated form bean and
>>validate="true". The request is delegated to the ActionServlet, the action
>>servlet calls reset on the form, populates the form properties, then
>>validates. Upon successful validation the action does a bit of work and
>>then forwards to the 2nd action.
>>
>>The 2nd action also has the same form bean associated with it. I noticed
>>that the ActionServlet again calls reset on the form, populates the form
>>parameters and then passes the form to the action. I guess this is the
>>desired behavior and don't think there is a bug in struts.
>>
>>The two issues I found are:
>>
>>1) It does seem unnecessary to reset/populate the form after it has already
>>been done once. What if I chained 5 actions. That would be a lot of
>>processing power to reset/populate the form 5 times.
>>
>>2) I only noticed that this happens because we have one action that sets a
>>property one way during the work and then forwards to the 2nd action, but
>>then when the 2nd action gets the form, the property has been reset back to
>>the state of the request parameter. We had to workaround this by not
>>associating the form with the action and then manually looking it up from
>>the request object.
>>
>>I'd like to know if anyone has experienced a similar type of situation and
>>what they did to make things work the most strutsy way.
>>
>>Comments appreciated
>>Thanks
>>Dennis
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: struts-user-help@jakarta.apache.org
>>
>>
>>
>
>_________________________________________________________________
>Add photos to your messages with MSN 8. Get 2 months FREE*.
>http://join.msn.com/?page=features/featuredemail
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: struts-user-help@jakarta.apache.org
>
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org