You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Gena Batsyan <gb...@gmail.com> on 2007/05/16 15:20:12 UTC
forwarding to another action passing parameters
This is a Struts 2 question.
I'm looking for a common solution to the problem stated in the subject.
The easiest way to explain what exactly I want is with an example.
I have two actions:
1) ListAction, that displays a list of database entries.
2) CreateAction, that receives input from a form, creates a new entry in
the database and passes control to the ListAction.
The last thing to say about the ListAction is that it should be able to
display messages like "entry successfully created" if it is executed
after CreateAction (as described above).
Following things are important for me:
1) Both actions must run within the same HTTP request from browser.
(don't really care how many HttpRequest instances are created.)
2) The ListAction should NOT receive any of the parameters, received by
CreateAction. (a new clean HttpRequest for ListAction would be actually
ideal)
Please don't tell me something like "if the action properties of both
action classes don't match, the parameters won't be transferred anyway"
or "use another method instead of execute". _I want to avoid any effort
of ensuring that no accidental parameter interference between the two
actions occurs_.
3) it should be able to specify explicitely (via struts.xml or within
the execute() of CreateAction) which parameters I want to pass to
ListAction.
4) I DON'T want to pass parameters through session.
I have tried following things, neither of which satisfies me:
1) for CreateAction use result type="redirect-action" and use dynamic
parameters in struts.xml.
Don't like this approach because there are two requests from browser and
the parameters are passed through an URI of the second request. Thus I'm
unable to easily pass anything more complicated than a string and
finally I don't want to dispose any internal stuff through URLs visible
in the browser.
2) use result type="chain"
As far as I can see this thing is designed to allow two actions to
process the same HttpRequest (If I'm wrong or missing something a
comment is appreciated)
Which is again NOT what I want. If the ListAction accidentally
recognizes some parameters recognized by CreateAction, I will have a
problem.
Further using this approach I have tried to clear() the request Map
(obtained through RequestAware) but when this is done, the JSP of
ListAction won't display any ListAction properties. Obviously clear()
breaks some essentials. (it kills the valuestack object in the request
map as far as I have seen while debugging, which for some obscure reason
prevents the final JSP to obtain any of the properties of ListAction).
Thus my question is:
What's the right way of forwarding to another action, having a clean
request for this another action but being able to pass some parameters
from the initial action.
This is a simple requirement, that is needed in almost any webapp I can
imagine, and I absolutely believe something like this must be a core
feature.
But I simply don't see a solution after spending several days on it!
Any ideas or comments heavily appreciated!
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: forwarding to another action passing parameters
Posted by Dale Newfield <Da...@Newfield.org>.
Gena Batsyan wrote:
> Why not, we have two actions with absolutely distinct purposes, one for
> entry creation and another for entity listing, but the listing has a
> little feature to display messages.
If you have two actions you want to expose to your users, then by all
means they should both be web actions. If you only want one of them to
be exposed through your web interface, and you are afraid of security
implications resulting from unexpected arguments to the other, then
maybe they shouldn't both be web actions. You've got to decide what
your requirements are before you can decide how to implement them, and
how similar/dissimilar they should be.
-Dale
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: forwarding to another action passing parameters
Posted by Gena Batsyan <gb...@gmail.com>.
Dale Newfield wrote:
> Gena Batsyan wrote:
>> As I said, if using chain, the whole load of parameters is applied to
>> the second action, which I want to avoid, I want it to get nothing
>> except of what I'm explicitly define.
>
> It sounds like you're trying to use the wrong tools. You're looking
> for a way to trigger the creation of an object, but you don't want to
> let the browser know that an action that does this exists, and you
> don't want to allow any other than a specific few parameters to get to
> that action. Then why does it need to be a (web layer) struts action?
> Sounds like it should be a method call in a manager class. The action
> from which you're trying to chain should really just be collecting all
> the bits you approve of and making a method call.
Why not, we have two actions with absolutely distinct purposes, one for
entry creation and another for entity listing, but the listing has a
little feature to display messages.
>
>
> -Dale
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: forwarding to another action passing parameters
Posted by Dale Newfield <Da...@Newfield.org>.
Gena Batsyan wrote:
> As I said, if using chain, the whole load of parameters is applied to
> the second action, which I want to avoid, I want it to get nothing
> except of what I'm explicitly define.
It sounds like you're trying to use the wrong tools. You're looking for
a way to trigger the creation of an object, but you don't want to let
the browser know that an action that does this exists, and you don't
want to allow any other than a specific few parameters to get to that
action. Then why does it need to be a (web layer) struts action?
Sounds like it should be a method call in a manager class. The action
from which you're trying to chain should really just be collecting all
the bits you approve of and making a method call.
-Dale
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: forwarding to another action passing parameters
Posted by Dave Newton <ne...@yahoo.com>.
--- Christopher Schultz wrote:
> Dave Newton wrote:
>> Someone else may have a better idea, but I think
>> this is just the nature of the way HTTP works: you
>> can forward or redirect; forward means you get the
>> same request, redirect means you get a new one.
>
> I'm not entirely sure this is true, at least not
> through Struts. For instance, I have actions that
> forward to other actions and add request
> parameters along the way. I do this by returning an
> ActionForward from
> the first action which contains GET-style parameters
> added to the path.
> One way or another, the request as viewed by the
> second action (via
> forward, not redirect) gets those newly-added
> parameters.
Sure, you can *modify* the request, but AFAIK it's
still the same request (at least from a logical
standpoint) as opposed to a redirect which is an
entirely new one.
d.
____________________________________________________________________________________
Park yourself in front of a world of choices in alternative vehicles. Visit the Yahoo! Auto Green Center.
http://autos.yahoo.com/green_center/
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: forwarding to another action passing parameters
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Dave,
Dave Newton wrote:
> Someone else may have a better idea, but I think this is just the
> nature of the way HTTP works: you can forward or redirect; forward
> means you get the same request, redirect means you get a new one.
I'm not entirely sure this is true, at least not through Struts. For
instance, I have actions that forward to other actions and add request
parameters along the way. I do this by returning an ActionForward from
the first action which contains GET-style parameters added to the path.
One way or another, the request as viewed by the second action (via
forward, not redirect) gets those newly-added parameters.
Perhaps the original request is wrapped in something that makes it look
like additional parameters have been added, so you get a sort-of
aggregate request.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGS0i+9CaO5/Lv0PARAntEAKCRkdx/J/XlhkhWuhTeaSruX+lMHwCeJx6d
y+HCxEFxJ7NolfR+7kCb24s=
=5MTJ
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: forwarding to another action passing parameters
Posted by Dave Newton <ne...@yahoo.com>.
--- Gena Batsyan <gb...@gmail.com> wrote:
> Dave Newton wrote:
> > --- Gena Batsyan <gb...@gmail.com> wrote:
> > Messages for that are generally stored in a
> > "flash"-like context (session but with automagic
> > removal after the next request completes).
> that' Interesting. Where can I read about flash-like
> context you are talking about?
Um... I'm not sure. I would have sworn I remember
somebody talking about it on this list within the last
week or so, but wouldn't swear by it; maybe somebody
was talking about a flash-scope interceptor?
In any case, the concept is simple: something gets put
into flash-scope (which is just a chunk of data in the
session) for the *next* request only, then is
automatically removed. It should be a pretty simple
interceptor, and it's a very useful beast, since it
can hold *anything*, not just simple strings.
>> If your list action isn't ParameterAware it won't
>> get any params anyway, I believe.
> Sure, but what if I still want it to be able to get
> some parameters other than from redirect
That would be a problem.
> As I said, if using chain, the whole load of
> parameters is applied to the second action, which I
> want to avoid, I want it to get nothing except of
> what I'm explicitly define.
Someone else may have a better idea, but I think this
is just the nature of the way HTTP works: you can
forward or redirect; forward means you get the same
request, redirect means you get a new one.
So you'd either need to strip, or re-create, the
request parameters you're interested in.
You might be able to put objects on the OGNL stack via
ActionContext before a chained action and get at them
that way, perhaps.
d.
____________________________________________________________________________________Looking for a deal? Find great prices on flights and hotels with Yahoo! FareChase.
http://farechase.yahoo.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: forwarding to another action passing parameters
Posted by Gena Batsyan <gb...@gmail.com>.
Dave Newton wrote:
> --- Gena Batsyan <gb...@gmail.com> wrote:
>
>> This is a simple requirement, that is needed in
>> almost any webapp I can imagine, and I absolutely
>> believe something like this must be a core
>> feature.
>>
>
> I'm not entirely sure I complete understand what
> you're asking for.
>
> The *most* common solution for this is a
> post-redirect(-get) where the form is posted,
> processed, and you redirect to the list.
>
> Messages for that are generally stored in a
> "flash"-like context (session but with automagic
> removal after the next request completes).
>
>
that' Interesting. Where can I read about flash-like context you are
talking about?
> If your list action isn't ParameterAware it won't get
> any params anyway, I believe.
>
>
Sure, but what if I still want it to be able to get some parameters
other than from redirect
(I don't want to limit this action in any way)
>> (it kills the valuestack object in the request
>> map as far as I have seen while debugging, which for
>>
>
>
>> some obscure reason prevents the final JSP to obtain
>>
>
>
>> any of the properties of ListAction)
>>
>
> Some "obscure reason?" The value stack is where the
> properties of the list action are *kept*. Of course if
> you remove it the properties will be gone.
>
>
The funny thing is that cleaning request map in the first action totally
breaks the second action.
if you have a getter in the second action it simply returns nothing when
accessed through OGNL from JSP. That's weird.
> If you want to forward, the "best" way to do it is
> with an action-chain. If you want to redirect then you
> need to have some way of storing the message, like you
> said.
>
>
As I said, if using chain, the whole load of parameters is applied to
the second action, which I want to avoid, I want it to get nothing
except of what I'm explicitly define.
> That's just the nature of HTTP, AFAICT. You can work
> *around* the limitations of HTTP with interceptors,
> parameter map tweaking, etc. but you can't *avoid*
> those limitations.
>
> Someone else might be more helpful, though.
>
> d.
>
>
>
>
> ____________________________________________________________________________________Pinpoint customers who are looking for what you sell.
> http://searchmarketing.yahoo.com/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: forwarding to another action passing parameters
Posted by Dave Newton <ne...@yahoo.com>.
--- Gena Batsyan <gb...@gmail.com> wrote:
> This is a simple requirement, that is needed in
> almost any webapp I can imagine, and I absolutely
> believe something like this must be a core
> feature.
I'm not entirely sure I complete understand what
you're asking for.
The *most* common solution for this is a
post-redirect(-get) where the form is posted,
processed, and you redirect to the list.
Messages for that are generally stored in a
"flash"-like context (session but with automagic
removal after the next request completes).
If your list action isn't ParameterAware it won't get
any params anyway, I believe.
> (it kills the valuestack object in the request
> map as far as I have seen while debugging, which for
> some obscure reason prevents the final JSP to obtain
> any of the properties of ListAction)
Some "obscure reason?" The value stack is where the
properties of the list action are *kept*. Of course if
you remove it the properties will be gone.
If you want to forward, the "best" way to do it is
with an action-chain. If you want to redirect then you
need to have some way of storing the message, like you
said.
That's just the nature of HTTP, AFAICT. You can work
*around* the limitations of HTTP with interceptors,
parameter map tweaking, etc. but you can't *avoid*
those limitations.
Someone else might be more helpful, though.
d.
____________________________________________________________________________________Pinpoint customers who are looking for what you sell.
http://searchmarketing.yahoo.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org