You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by "Thompson, David" <Da...@sunmed.com> on 2003/09/17 21:25:58 UTC
Chained Actions (why so bad?), forwards vs. redirects, and Tiles
I'm still not seeing why 'chained' actions are so bad. On our current
project, we want a user who has just signed up to go ahead and be logged-in
all in the same step, and forwarded straight to the logged-in homepage.
There are 2 actions, and using 1.1b3 with Tiles, the following struts-config
worked just fine:
<action path="/signup"
...
<forward name="login" path="login.do"/>
</action>
<action path="/login"
...
<forward name="success" path="tile.homepage"/>
</action>
We even figured out that you could specify the next 'link' of the chain with
it's own request parameters, ala path="login.do?someparm=hello". Note that
it _forwarded_ to the next action (same request object, so we could pass
data as attributes), and re-triggering the dispatcher was a-ok. So then we
switched to 1.1final, and noticed this doesn't work any more ("Cannot get
request dispatcher for path..."). Now, I can understand how pulling
path="login.do?someparm=hello" in a forward shouldn't work (even stepping
through the code, I still can't figure out how it was working before), but
for a number of circumstances, I still want to be able to _forward_ to other
actions.
Why is that so bad? I'm not entirely seeing how it's breaking the MVC
pattern. The intent of an action is to perform a discreet activity so
you're not duplicating code everywhere, so to get 2 or more to execute on
one request seems completely within reason. I realize there's no way to
change request parameters, so yes, I'd be using request attributes to pass
data between actions, so I suppose that's the whole riff over chained
actions? the 'bad' practice of using request attributes? Would it be bad
if I didn't need to pass anything to the next action? I'd argue using a
redirect (<forward redirect="true"...) can be looked down on too, as it can
be effected by the visitor's browser, play tricks on hit logging and
clickstream tracking systems, potentially leave slow-connection users with
blank screens, etc. but I digress...
In _lieu_ (;^) of being able to forward to other actions, I can think of a
number of other ways to work this. For a second action in the chain who
wants a simple, request-scoped form, I don't mind having the first action
create a form and set data, place it on the request, and use a mapping to
the next action. Or, change the form to be session scoped, create the form
and set data, place it in the session (you'd have to use the struts-config
given name as the key, and that'd be icky), use a redirect="true" mapping to
get to the second action, have the second action remove it from the session.
Or, have the first action create a full URL to the second action, with query
string to pass parameters in, and return a redirected ActionForward (oh the
semantics!). Then complicate matters of how to add, and ensure use of,
https in this mix. whew.
Thanks,
david
+1-303-218-4716 work³
+1-303-521-8967 mobile
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
RE: Chained Actions (why so bad?), forwards vs. redirects, and Tiles
Posted by Andrew Hill <an...@gridnode.com>.
<snip>
Now, I can understand how pulling
path="login.do?someparm=hello" in a forward shouldn't work (even stepping
through the code, I still can't figure out how it was working before
</snip>
Theres no problem slipping query params into a forward url like that. Its a
standard technique. All my apps depend on it. Look elsewhere for your bug
for it lyeth not in the forwarded params.
btw: redirecting to another action is not action chaining. Its only chaining
if you do it on the server side (non-redirecting), and its only evil as you
can get (a lot of) unanticipated side-effects from a second pass through the
request processor (such as form repopulation)
-----Original Message-----
From: Thompson, David [mailto:David.Thompson@sunmed.com]
Sent: Thursday, 18 September 2003 03:26
To: 'struts-user@jakarta.apache.org'
Subject: Chained Actions (why so bad?), forwards vs. redirects, and
Tiles
I'm still not seeing why 'chained' actions are so bad. On our current
project, we want a user who has just signed up to go ahead and be logged-in
all in the same step, and forwarded straight to the logged-in homepage.
There are 2 actions, and using 1.1b3 with Tiles, the following struts-config
worked just fine:
<action path="/signup"
...
<forward name="login" path="login.do"/>
</action>
<action path="/login"
...
<forward name="success" path="tile.homepage"/>
</action>
We even figured out that you could specify the next 'link' of the chain with
it's own request parameters, ala path="login.do?someparm=hello". Note that
it _forwarded_ to the next action (same request object, so we could pass
data as attributes), and re-triggering the dispatcher was a-ok. So then we
switched to 1.1final, and noticed this doesn't work any more ("Cannot get
request dispatcher for path..."). Now, I can understand how pulling
path="login.do?someparm=hello" in a forward shouldn't work (even stepping
through the code, I still can't figure out how it was working before), but
for a number of circumstances, I still want to be able to _forward_ to other
actions.
Why is that so bad? I'm not entirely seeing how it's breaking the MVC
pattern. The intent of an action is to perform a discreet activity so
you're not duplicating code everywhere, so to get 2 or more to execute on
one request seems completely within reason. I realize there's no way to
change request parameters, so yes, I'd be using request attributes to pass
data between actions, so I suppose that's the whole riff over chained
actions? the 'bad' practice of using request attributes? Would it be bad
if I didn't need to pass anything to the next action? I'd argue using a
redirect (<forward redirect="true"...) can be looked down on too, as it can
be effected by the visitor's browser, play tricks on hit logging and
clickstream tracking systems, potentially leave slow-connection users with
blank screens, etc. but I digress...
In _lieu_ (;^) of being able to forward to other actions, I can think of a
number of other ways to work this. For a second action in the chain who
wants a simple, request-scoped form, I don't mind having the first action
create a form and set data, place it on the request, and use a mapping to
the next action. Or, change the form to be session scoped, create the form
and set data, place it in the session (you'd have to use the struts-config
given name as the key, and that'd be icky), use a redirect="true" mapping to
get to the second action, have the second action remove it from the session.
Or, have the first action create a full URL to the second action, with query
string to pass parameters in, and return a redirected ActionForward (oh the
semantics!). Then complicate matters of how to add, and ensure use of,
https in this mix. whew.
Thanks,
david
+1-303-218-4716 work³
+1-303-521-8967 mobile
---------------------------------------------------------------------
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