Does Struts 2 solve the action chaining problem?

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Does Struts 2 solve the action chaining problem?

Tarek Nabil-2
Hi,

One of the problems with Struts was that if you had a page that requires
some setup and this page submits to an Action, then you would not be
able to set validate to true on that action because if validation
problems occur then Struts will take you directly to the input JSP
without performing the setup and your JSP wouldn't work.

A solution to that would be to specify the input of the action as the
setup action, which means you're doing action chaining and Struts is not
good at that (it will reset your form among other things).

The solution of choice for us so far was to call validate() ourselves in
the action and if a validation problem occurs then we call the setup
method (eventually you start using your action methods as an API which
still was not good).

Another problematic scenario is the case when you're editing some
database record for example. When you go to your setup action for the
first time, you will populate drop down lists for example, and then load
the existing values from the database to your JSP fields. If the user
attempts to save and some problem occurs then in the setup action, you
will need to again populate the drop down lists, but you will NOT want
to overwrite the user's inputs with the existing data. This is very
similar to the first problem, but you would also need to pass some flag
to the setup method to tell it whether to copy the data from the
database to your ActionForm.

Does Struts 2 or even WW 2.2.4 solve that problem in an elegant way? I
remember coming across something about using Interceptors for that, but
that would mean creating an Interceptor for almost every action of that
type. I also noticed that there are some warnings in the documentation
against using action chaining in Struts 2 as well.

Thanks,
Tarek Nabil
********************************************DISCLAIMER********************************************
This email and any files transmitted with it are confidential and contain privileged or copyright
information. If you are not the intended recipient you must not copy, distribute or use this email
or the information contained in it for any purpose other than to notify us of the receipt thereof.
If you have received this message in error, please notify the sender immediately, and delete this
email from your system.

Please note that e-mails are susceptible to change.The sender shall not be liable for the improper
or incomplete transmission of the information contained in this communication,nor for any delay in
its receipt or damage to your system.The sender does not guarantee that this material is free from
viruses or any other defects although due care has been taken to minimise the risk.
**************************************************************************************************

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Does Struts 2 solve the action chaining problem?

craigmcc
On 11/28/06, Tarek Nabil <[hidden email]> wrote:

>
> Hi,
>
> One of the problems with Struts was that if you had a page that requires
> some setup and this page submits to an Action, then you would not be
> able to set validate to true on that action because if validation
> problems occur then Struts will take you directly to the input JSP
> without performing the setup and your JSP wouldn't work.
>
> A solution to that would be to specify the input of the action as the
> setup action, which means you're doing action chaining and Struts is not
> good at that (it will reset your form among other things).
>
> The solution of choice for us so far was to call validate() ourselves in
> the action and if a validation problem occurs then we call the setup
> method (eventually you start using your action methods as an API which
> still was not good).
>
> Another problematic scenario is the case when you're editing some
> database record for example. When you go to your setup action for the
> first time, you will populate drop down lists for example, and then load
> the existing values from the database to your JSP fields. If the user
> attempts to save and some problem occurs then in the setup action, you
> will need to again populate the drop down lists, but you will NOT want
> to overwrite the user's inputs with the existing data. This is very
> similar to the first problem, but you would also need to pass some flag
> to the setup method to tell it whether to copy the data from the
> database to your ActionForm.
>
> Does Struts 2 or even WW 2.2.4 solve that problem in an elegant way? I
> remember coming across something about using Interceptors for that, but
> that would mean creating an Interceptor for almost every action of that
> type. I also noticed that there are some warnings in the documentation
> against using action chaining in Struts 2 as well.


Interceptors are an O-O oriented approach to this kind of issue, but there
are ligther weight alternatives. For the particular need of a "setup"
action, consider the use of the Preparable interface in Struts 2.  It's
pretty similar to what the Tiles "Controller" interface supported in Struts
1.x ... a chance for your business logic to set up the stuff that is needed
for rendering a particular view.

If you're looking at JSF as a view technology, you'll likely be interested
in what Shale <http://shale.apache.org/"> has to offer, particularly in the
View Controller feature.  Not only does the View Controller functionality
support the setup scenario (via the prerender() callback method on the
ViewController interface), it also supports cleaning up *after* the view has
been rendered, via the destroy() callback.

Craig
Reply | Threaded
Open this post in threaded view
|

Re: Does Struts 2 solve the action chaining problem?

Yujun Liang-2
To solve the action chaining problem, I wrote a subclass of
RequestProcessor. In the subclass, override some templates method. In the
last method of process(), I set a flag in request, and I check for this flag
in some methods and if the flag is there, it means it is the chained action
and the processor will skip those template methods.

I think at least the following methods don't need to be executed in the
chained actions,
processHeader
processLocale,
processPopulate,
processValidate,

I solved the action chaining problem by extending the RequestProcessor, and
it also improved the performance.

For version 1.2.9

Regards

On 11/29/06, Craig McClanahan <[hidden email]> wrote:

>
> On 11/28/06, Tarek Nabil <[hidden email]> wrote:
> >
> > Hi,
> >
> > One of the problems with Struts was that if you had a page that requires
> > some setup and this page submits to an Action, then you would not be
> > able to set validate to true on that action because if validation
> > problems occur then Struts will take you directly to the input JSP
> > without performing the setup and your JSP wouldn't work.
> >
> > A solution to that would be to specify the input of the action as the
> > setup action, which means you're doing action chaining and Struts is not
> > good at that (it will reset your form among other things).
> >
> > The solution of choice for us so far was to call validate() ourselves in
> > the action and if a validation problem occurs then we call the setup
> > method (eventually you start using your action methods as an API which
> > still was not good).
> >
> > Another problematic scenario is the case when you're editing some
> > database record for example. When you go to your setup action for the
> > first time, you will populate drop down lists for example, and then load
> > the existing values from the database to your JSP fields. If the user
> > attempts to save and some problem occurs then in the setup action, you
> > will need to again populate the drop down lists, but you will NOT want
> > to overwrite the user's inputs with the existing data. This is very
> > similar to the first problem, but you would also need to pass some flag
> > to the setup method to tell it whether to copy the data from the
> > database to your ActionForm.
> >
> > Does Struts 2 or even WW 2.2.4 solve that problem in an elegant way? I
> > remember coming across something about using Interceptors for that, but
> > that would mean creating an Interceptor for almost every action of that
> > type. I also noticed that there are some warnings in the documentation
> > against using action chaining in Struts 2 as well.
>
>
> Interceptors are an O-O oriented approach to this kind of issue, but there
> are ligther weight alternatives. For the particular need of a "setup"
> action, consider the use of the Preparable interface in Struts 2.  It's
> pretty similar to what the Tiles "Controller" interface supported in
> Struts
> 1.x ... a chance for your business logic to set up the stuff that is
> needed
> for rendering a particular view.
>
> If you're looking at JSF as a view technology, you'll likely be interested
> in what Shale <http://shale.apache.org/"> has to offer, particularly in
> the
> View Controller feature.  Not only does the View Controller functionality
> support the setup scenario (via the prerender() callback method on the
> ViewController interface), it also supports cleaning up *after* the view
> has
> been rendered, via the destroy() callback.
>
> Craig
>
>


--
Yujun Liang
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Does Struts 2 solve the action chaining problem?

Mark Menard
In reply to this post by Tarek Nabil-2
On 11/29/06 12:44 AM, "Tarek Nabil" <[hidden email]> wrote:

> One of the problems with Struts was that if you had a page that requires
> some setup and this page submits to an Action, then you would not be
> able to set validate to true on that action because if validation
> problems occur then Struts will take you directly to the input JSP
> without performing the setup and your JSP wouldn't work.

Yes, that can be an issue in Struts 1, as far as I know, but then again I
never did serious Struts 1 development.

As for S2 it's not an issue. With a reasonably configured interceptor stack
and the use of the Preparable interface the issue doesn't exist.
 
> A solution to that would be to specify the input of the action as the
> setup action, which means you're doing action chaining and Struts is not
> good at that (it will reset your form among other things).

I haven't found a need for chaining yet in my S2 development. Using the
prepare() method has sufficed for me.
 
> The solution of choice for us so far was to call validate() ourselves in
> the action and if a validation problem occurs then we call the setup
> method (eventually you start using your action methods as an API which
> still was not good).

Agreed, it would be nice if it just happened. You can do this in S2.
Basically I have my interceptor stack configured to apply parameters to my
action, run prepare, apply parameters again, then validate, then execute.
All very neat.
 

> Another problematic scenario is the case when you're editing some
> database record for example. When you go to your setup action for the
> first time, you will populate drop down lists for example, and then load
> the existing values from the database to your JSP fields. If the user
> attempts to save and some problem occurs then in the setup action, you
> will need to again populate the drop down lists, but you will NOT want
> to overwrite the user's inputs with the existing data. This is very
> similar to the first problem, but you would also need to pass some flag
> to the setup method to tell it whether to copy the data from the
> database to your ActionForm.

Again I think the well configured interceptor stack has you covered. If you
apply parameters after your prepare the users input will over write the
values you've retrieved from the database, thereby preserving their input.

Alternatively you could prepare the "model" once for the duration of the
users interaction with a "process" by storing the data in the user's
session, or in a conversation scope (cf. JIRA WW-1514 for an idea on how to
do this, note this interceptor/interface is not done yet, nor is it
official).
 
> Does Struts 2 or even WW 2.2.4 solve that problem in an elegant way? I
> remember coming across something about using Interceptors for that, but
> that would mean creating an Interceptor for almost every action of that
> type. I also noticed that there are some warnings in the documentation
> against using action chaining in Struts 2 as well.

Can't speak to the chaining issues. But as I've written I think you can
solve the whole issue using the Prepareable interface and a well configured
interceptor stack. Also, remember that you don't need to use the same stack
for every action. You can apply interceptor stacks at the action and package
level. That makes it pretty easy to manage.

Take care,

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Does Struts 2 solve the action chaining problem?

Christopher Schultz-2
In reply to this post by Tarek Nabil-2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Tarek,

Tarek Nabil wrote:

> One of the problems with Struts was that if you had a page that requires
> some setup and this page submits to an Action, then you would not be
> able to set validate to true on that action because if validation
> problems occur then Struts will take you directly to the input JSP
> without performing the setup and your JSP wouldn't work.
>
> A solution to that would be to specify the input of the action as the
> setup action, which means you're doing action chaining and Struts is not
> good at that (it will reset your form among other things).
>
> The solution of choice for us so far was to call validate() ourselves in
> the action and if a validation problem occurs then we call the setup
> method (eventually you start using your action methods as an API which
> still was not good).

I totally disagree. If you have an action that you want to use like
this, you can always set up two different mappings -- one that /does/
validate and another that does /not/ validate.

My experience has been that Struts is very good at "action chaining"...
in fact, that's the major advantage of Struts in the first place: the
ability to map URIs to actions and specify their relationships through
forward mappings.

> Another problematic scenario is the case when you're editing some
> database record for example. When you go to your setup action for the
> first time, you will populate drop down lists for example, and then load
> the existing values from the database to your JSP fields. If the user
> attempts to save and some problem occurs then in the setup action, you
> will need to again populate the drop down lists, but you will NOT want
> to overwrite the user's inputs with the existing data. This is very
> similar to the first problem, but you would also need to pass some flag
> to the setup method to tell it whether to copy the data from the
> database to your ActionForm.

In this case, what you want is something like:

LoadAction -> EditAction -> Display form

Form submits to SaveAction, which has EditAction as input (not LoadAction).

This is pretty standard stuff, and works beautifully.

> Does Struts 2 or even WW 2.2.4 solve that problem in an elegant way?

I really hope so, since Struts 1.x also does.

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFbYyx9CaO5/Lv0PARArpHAJ0U3fHybMWepSZxPjciDU3+6M2PwQCgoy8B
FRlfdQsyONpgqGvrHBuZuFw=
=EbD/
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: Does Struts 2 solve the action chaining problem?

Tarek Nabil-2
In reply to this post by Tarek Nabil-2
Craig and Mark,

Thanks a lot for pointing out the "Preparable" interface. I think that
solves a major problem with Struts 1. I'm yet to experiment heavily with
WW/Struts 2, but I feel like the "Interceptor" concept is a very
powerful approach, though a bit dangerous if not well controlled.

Craig,

We, actually, decided that we don't want to get into JSF yet. But if
this "prerender" method is equivalent to the "onPageLoad()" method in
ASP .NET, then it's a very important piece that is really missing from
the JSF spec.

Yujun,

Your idea is brilliant and it never crossed my mind. If we stick with
Struts 1, I think I will try that.

Christopher,

I really wonder if the Struts you're talking about is the one I've using
for years now!! The Struts I know sucks big time when it comes to action
chaining. I'm afraid I don't understand how defining two mappings, one
with validation turned on and the other turned off, solves the first
problem! As for the second problem, your solution still involves action
chaining which should be avoided unless you've done something equivalent
to what Yujun did.

Thanks everyone for your help.

-----Original Message-----
From: Christopher Schultz [mailto:[hidden email]]
Sent: Wednesday, November 29, 2006 5:36 PM
To: Struts Users Mailing List
Subject: Re: Does Struts 2 solve the action chaining problem?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Tarek,

Tarek Nabil wrote:
> One of the problems with Struts was that if you had a page that
requires
> some setup and this page submits to an Action, then you would not be
> able to set validate to true on that action because if validation
> problems occur then Struts will take you directly to the input JSP
> without performing the setup and your JSP wouldn't work.
>
> A solution to that would be to specify the input of the action as the
> setup action, which means you're doing action chaining and Struts is
not
> good at that (it will reset your form among other things).
>
> The solution of choice for us so far was to call validate() ourselves
in
> the action and if a validation problem occurs then we call the setup
> method (eventually you start using your action methods as an API which
> still was not good).

I totally disagree. If you have an action that you want to use like
this, you can always set up two different mappings -- one that /does/
validate and another that does /not/ validate.

My experience has been that Struts is very good at "action chaining"...
in fact, that's the major advantage of Struts in the first place: the
ability to map URIs to actions and specify their relationships through
forward mappings.

> Another problematic scenario is the case when you're editing some
> database record for example. When you go to your setup action for the
> first time, you will populate drop down lists for example, and then
load
> the existing values from the database to your JSP fields. If the user
> attempts to save and some problem occurs then in the setup action, you
> will need to again populate the drop down lists, but you will NOT want
> to overwrite the user's inputs with the existing data. This is very
> similar to the first problem, but you would also need to pass some
flag
> to the setup method to tell it whether to copy the data from the
> database to your ActionForm.

In this case, what you want is something like:

LoadAction -> EditAction -> Display form

Form submits to SaveAction, which has EditAction as input (not
LoadAction).

This is pretty standard stuff, and works beautifully.

> Does Struts 2 or even WW 2.2.4 solve that problem in an elegant way?

I really hope so, since Struts 1.x also does.

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFbYyx9CaO5/Lv0PARArpHAJ0U3fHybMWepSZxPjciDU3+6M2PwQCgoy8B
FRlfdQsyONpgqGvrHBuZuFw=
=EbD/
-----END PGP SIGNATURE-----
********************************************DISCLAIMER********************************************
This email and any files transmitted with it are confidential and contain privileged or copyright
information. If you are not the intended recipient you must not copy, distribute or use this email
or the information contained in it for any purpose other than to notify us of the receipt thereof.
If you have received this message in error, please notify the sender immediately, and delete this
email from your system.

Please note that e-mails are susceptible to change.The sender shall not be liable for the improper
or incomplete transmission of the information contained in this communication,nor for any delay in
its receipt or damage to your system.The sender does not guarantee that this material is free from
viruses or any other defects although due care has been taken to minimise the risk.
**************************************************************************************************

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Does Struts 2 solve the action chaining problem?

Ted Husted
Action Chaining

First, we usually define "action chaining" as creating a "move" action
by having a "copy" action forward to a "delete" action. Simply going
from one action to another isn't a classic example of harmful
chaining. The key point is whether only one action resolves the
business use case.

Classic action chaining is considered harmful because it implies that
the Actions have become a business facade. Any Action should be able
to call facade.copy and facade.delete from a move Action. Better yet,
the facade should provide a move method, and implement it any way it
likes. We should not feel like we need to reuse multiple Action
classes to solve one business use case. Struts 1 Actions were intended
to be what Martin Fowler calls a "transaction script", where "move" is
one transaction, not two.

The design of Struts 1 made action chaining difficult because s1
repopulates the request on every forward. When people start to use the
S1 actions as an API, they want to do things like change properites on
an ActionForm, and are surprised when the framework resets their
changes!

The Struts 2 group does discourgage classic Action chaining, because
it implies the business API is underdevelpoed. Albeit, we do provide a
action chaining result that copies the properties from one Action to
the next. The interceptor stack and result are processed for the
chained action, but the request doesn't pass back through the
container.

* http://struts.apache.org/2.x/docs/action-chaining.html

So you can set a flag on the copy action and have it picked up by the
delete action. This is *not* considered an ideal practice, since
coupling individual Action classes complicates the API, but it's there
when people choose to use it.

So, yes, Struts 2 has an elegant solution for action chaining, if you
choose to use it.

Control preparation

As mentioned, Struts 2 solves the control population issue via the
preparable interface. Another solution is to use the action tag to
execute an Action in place.

* http://cwiki.apache.org/confluence/display/WW/action

One way to use this tag is to put a control on a "snippet" JSP that is
rendered as a result of an Action that does nothing but create the
object that populates the control. The action tag sets
"executeresult=true", then control markup will be "included" into the
page (like a tile), after the action executes.

In effect, exectuteResult actions can be used like a tag that can run
its own action before emitting the markup.

Input.jsp

<%@ taglib prefix="s" uri="/struts-tags" %>
<s:form>
    <s:action name="languages" namespace="/ActionTag" executeResult="true"/>
    <s:action name="colors" namespace="/ActionTag" executeResult="true"/>
    <ssubmit/>
</s::form>

Languages.jsp

<%@ taglib prefix="s" uri="/struts-tags" %>
<s:select
        tooltip="Choose Your Favorite Language"
        label="Favorite Language"
        list="favoriteLanguages"
        name="favoriteLanguage"
        listKey="key"
        listValue="description"
        emptyOption="true"
        headerKey="None"
        headerValue="None"/>

Languages.java (execute)

    public String execute() {
        favoriteLanguages.add(new Select.Language("EnglishKey",
"English Language"));
        favoriteLanguages.add(new Select.Language("FrenchKey", "French
Language"));
        favoriteLanguages.add(new Select.Language("SpanishKey",
"Spanish Language"));
        return SUCCESS;
    }


struts.xml (Input, Languages)

        <action name="Input">
            <result type="plaintext">Input.jsp</result>
        </action>

        <action name="Languages" class="app.Languages">
            <result>Languages.jsp</result>
        </action>


The advantage being that the "Languages" action could be dropped in
whereever the "Languages" control is needed, and that the Action for
the form doesn't need to know how to populate the Languages control.

Now, the Action is going to be hit every time the page is rendered,
but so long as you are using a caching data access layer, like IBATIS
or Hibernate, it will end up being a memory-to-memory transfer, rather
than a database access.

-Ted.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Does Struts 2 solve the action chaining problem?

Michael Jouravlev
In reply to this post by Tarek Nabil-2
On 11/28/06, Tarek Nabil <[hidden email]> wrote:

> Hi,
>
> One of the problems with Struts was that if you had a page that requires
> some setup and this page submits to an Action, then you would not be
> able to set validate to true on that action because if validation
> problems occur then Struts will take you directly to the input JSP
> without performing the setup and your JSP wouldn't work.
>
> A solution to that would be to specify the input of the action as the
> setup action, which means you're doing action chaining and Struts is not
> good at that (it will reset your form among other things).
>
> The solution of choice for us so far was to call validate() ourselves in
> the action and if a validation problem occurs then we call the setup
> method (eventually you start using your action methods as an API which
> still was not good).
>
> Another problematic scenario is the case when you're editing some
> database record for example. When you go to your setup action for the
> first time, you will populate drop down lists for example, and then load
> the existing values from the database to your JSP fields. If the user
> attempts to save and some problem occurs then in the setup action, you
> will need to again populate the drop down lists, but you will NOT want
> to overwrite the user's inputs with the existing data. This is very
> similar to the first problem, but you would also need to pass some flag
> to the setup method to tell it whether to copy the data from the
> database to your ActionForm.

Struts 1.x works perfectly well in the above scenarios. You may want
to check out the overview of Struts action usage in  Struts wiki [1].
You can have one action handling both setup and input or you can have
two separate classes. Also, you can have two different action forms or
one action form.

Struts populates an action form automatically, which seems like too
much automation to me, but this cannot be changed now to ensure
backwards compatibility. The specifics of handling form bean
repopulation depend on chaining approach.

If you use in-server forwarding, then you will have to place a token
into the request object in the first action, and check this token in
the target action (actually, you will probably be checking this flag
in the form bean). If flag is there, this means that the action was
chained by forwarding, and you have to prohibit updating a form bean.
You can do this by putting an "if" into each and every setter of the
form bean. Quite clunky. If you use a different action form for a
chained action, you may want to define getters only, or to have setter
methods that do not correlate with URL parameters.

If you use redirection through browser, then just do not append any
parameters to the target URL, this way a redirected request will be
clean of parameters and Struts will not populate a form bean, because
it has nothing to populate with. What is more, you can use one
session-scoped form bean for both actions, it already has been set up,
so you don't it to reinitialize it.

[1] http://wiki.apache.org/struts/StrutsManualActionClasses

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Does Struts 2 solve the action chaining problem?

Michael Jouravlev
In reply to this post by Yujun Liang-2
On 11/29/06, Yujun Liang <[hidden email]> wrote:
> To solve the action chaining problem, I wrote a subclass of
> RequestProcessor. In the subclass, override some templates method. In the
> last method of process(), I set a flag in request, and I check for this flag
> in some methods and if the flag is there, it means it is the chained action
> and the processor will skip those template methods.

This is an approach that I've been using for quite a while, before I
switched to redirection. I think this feature can be included into
future releases of Struts 1.x.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Does Struts 2 solve the action chaining problem?

Hubert Rabago
If not this specific implementation, an otherwise clean way to handle
view preprocessing after a validation failure.  It can build on the
action-forward-specific command chain, but a solution that's more
tightly integrated with action objects should be considered as well.

Hubert

On 11/30/06, Michael Jouravlev <[hidden email]> wrote:

> On 11/29/06, Yujun Liang <[hidden email]> wrote:
> > To solve the action chaining problem, I wrote a subclass of
> > RequestProcessor. In the subclass, override some templates method. In the
> > last method of process(), I set a flag in request, and I check for this flag
> > in some methods and if the flag is there, it means it is the chained action
> > and the processor will skip those template methods.
>
> This is an approach that I've been using for quite a while, before I
> switched to redirection. I think this feature can be included into
> future releases of Struts 1.x.
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Does Struts 2 solve the action chaining problem?

Christopher Schultz-2
In reply to this post by Tarek Nabil-2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Tarek,

Tarek Nabil wrote:
> Christopher,
>
> I really wonder if the Struts you're talking about is the one I've using
> for years now!! The Struts I know sucks big time when it comes to action
> chaining. I'm afraid I don't understand how defining two mappings, one
> with validation turned on and the other turned off, solves the first
> problem! As for the second problem, your solution still involves action
> chaining which should be avoided unless you've done something equivalent
> to what Yujun did.

I suppose I've never tried to modify the state of the request (or form
bean) such that re-interpreting it across action invocations is
relevant. I typically get information out of a form bean ASAP and then
use that for some other operation (most often database interaction).
Then I discard the form bean.

If I have to re-read the form bean, it's in the same state in which I
left it.

I guess if you store a lot of state information in your form beans, and
you mutate that information in your actions, you might end up fighting
against Struts. As it is for me, forwarding from one action to another
(that both use the same form bean) results in no problems except a
slight performance hit for re-populating the bean and validating it when
entering the second action.

I never use beans that contain anything but Strings, so no conversion
ever needs to take place. It looks like my mode of use has resulted in
me never realizing what a PITA it might be when attempting to "chain
actions" in this way.

- -chris

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFb2by9CaO5/Lv0PARAtveAJ9AyWu4w0x7CUOuRvxXDjoKcVKbxwCfXCvc
licIhQWz58NCiqrqaR8XwO8=
=cSgU
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]