Re: [struts] Thanks! Works also with redirect actions...
Hi, i'm using Struts 2.1.8.
I have this struts configuration
action name=registrationMain class=somepackage.registrationAction
result name=redirect type=redirectAction
${customActionRedirect}?${urlParams}
true
/result
/action
I set the parameters to:
customActionRedirect=registrationConfirm
urlParams=documentID=200
and i want the final url to be something like this:
registrationConfirm.action?documentId=200
but the parameter is never used, and the id is lost.
Can you help me? What i'm doing wrong.
Thanks in advance.
DNewfield wrote:
Dave Newton wrote:
You mean on a Result type?
On the redirectAction result type.
Personally I'd prefer this as the *default* behavior
and force you to specify if you *did* want empty
parameters included, but that's just me.
I agree, but I don't think the patch should change current behavior,
just enable desired behavior.
This is probably more appropriately an XWork issue,
too, but it could be added to StrutsResultSupport (or
whatever that's called).
The patch I uploaded to the new JIRA issue (WW-2310) is against
org.apache.struts2.dispatcher.ServletActionRedirectResult .
Since I've still not even migrated from 2.0.9 to 2.0.11 it'll be a while
until I can benefit from this, but let's hope someone decides to test
and commit it.
-Dale
-
To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
For additional commands, e-mail: user-h...@struts.apache.org
--
View this message in context:
http://old.nabble.com/Redirects---Dynamic-Parameters-tp13609701p29761178.html
Sent from the Struts - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
For additional commands, e-mail: user-h...@struts.apache.org
Re: [struts] Thanks! Works also with redirect actions...
On 9/20/10 12:30 PM, martinib wrote:
action name=registrationMain class=somepackage.registrationAction
result name=redirect type=redirectAction
${customActionRedirect}?${urlParams}
true
/result
/action
I'm guessing there's some xml in there that some intermediate mail
process stripped out?
I set the parameters to:
customActionRedirect=registrationConfirm
urlParams=documentID=200
First of all while older documentation says to use ${}, %{} should now
work, and is less confusing (clearer that that's OGNL). It looks like
you've configured this to use the redirect result instead of the
redirect action result. I'm guessing you've made this mistake because
the documentation appears to be screwed up.
Unless I'm mistaken, the example on
http://struts.apache.org/2.1.8.1/docs/redirect-result.html is describing
the type of specification you should give for the redirectAction result.
Anyone with a clue care to chime in here?
http://struts.apache.org/2.1.8.1/docs/redirect-action-result.html does
appear to be correct, though, and you'd do well to model that example.
Assuming there's some way for those two parameters to get returned from
the valuestack (does your action have public String getUrlParams() and
public String getCustomActionRedirect()?), and you specified the
redirect result it would evaluate to
registrationConfirm?documentId=200 (no extension specified) which isn't
quite what you're looking for.
and i want the final url to be something like this:
registrationConfirm.action?documentId=200
but the parameter is never used, and the id is lost.
See above for a couple suggestions. If you're still having issues, post
again.
-Dale
-
To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
For additional commands, e-mail: user-h...@struts.apache.org
Re: [struts] Thanks! Works also with redirect actions...
--- Dale Newfield [EMAIL PROTECTED] wrote: ...any struts committers reading this: If I provided a patch for an extra specially named parameter like supressEmptyParameters that did just what you'd expect, what are the chances that someone would commit it? You mean on a Result type? Personally I'd prefer this as the *default* behavior and force you to specify if you *did* want empty parameters included, but that's just me. This is probably more appropriately an XWork issue, too, but it could be added to StrutsResultSupport (or whatever that's called). d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [struts] Thanks! Works also with redirect actions...
Dave Newton wrote: You mean on a Result type? On the redirectAction result type. Personally I'd prefer this as the *default* behavior and force you to specify if you *did* want empty parameters included, but that's just me. I agree, but I don't think the patch should change current behavior, just enable desired behavior. This is probably more appropriately an XWork issue, too, but it could be added to StrutsResultSupport (or whatever that's called). The patch I uploaded to the new JIRA issue (WW-2310) is against org.apache.struts2.dispatcher.ServletActionRedirectResult . Since I've still not even migrated from 2.0.9 to 2.0.11 it'll be a while until I can benefit from this, but let's hope someone decides to test and commit it. -Dale - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [struts] Thanks! Works also with redirect actions...
Gunnar Hillert wrote:
Thanks for your helpful post! Interestingly, this also works with redirect
actions.
Hrm...
The javadoc for ServletActionRedirectResult says:
This result uses the ActionMapper provided by the ActionMapperFactory
to redirect the browser to a URL that invokes the specified action
and (optional) namespace. This is better than the
ServletRedirectResult because it does not require you to encode the
URL patterns processed by the ActionMapper in to your struts.xml
configuration files. This means you can change your URL patterns at
any point and your application will still work. It is strongly
recommended that if you are redirecting to another action, you use
this result rather than the standard redirect result.
So it is clearly indicated that redirectAction is recommended over
redirect, but I neither understand why, nor quite what it is that this
result type does...
...it's still sending a redirect to the browser and causing the browser
to send a new request, correct? If so, the new request needs to have
the same URL (which must be encoded) no matter which result type
generated the redirect, correct? So what is it that this does better
than plain old redirect? Is it just that you can use structure the
request params in xml instead of constructing them inline from ognl
expressions?
If so, shouldn't this example:
result name=success type=redirectAction
mySuccess?fooId=${fooId}${bartId ? amp;barId= + barId : }
/result
instead be:
result name=success type=redirectAction
param name=actionNamemySuccess/param
param name=fooId${fooId}/param
param name=barId${barId}/param
/result
-Dale
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [struts] Thanks! Works also with redirect actions...
--- Dale Newfield [EMAIL PROTECTED] wrote:
So it is clearly indicated that redirectAction is
recommended over redirect, but I neither
understand why, nor quite what it is that this
result type does...
Precisely for the reasons stated; it adds a layer of
abstraction that understands action configuration.
Rather than specifying an actual URL with the
namespace, action name, and action suffix you just
give it an action name (and namespace param if
necessary).
It looks up the action in the config.
It's not like it's *hugely* better than redirect, it's
just that it keeps things in the framework.
instead be:
result name=success type=redirectAction
param name=actionNamemySuccess/param
param name=fooId${fooId}/param
param name=barId${barId}/param
/result
Arguably, yes, and for a couple of reasons. Off the
top of my head I don't recall what will happen if the
param isn't found, though (or is null, etc.)
d.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [struts] Thanks! Works also with redirect actions...
Dave Newton wrote:
result name=success type=redirectAction
param name=actionNamemySuccess/param
param name=fooId${fooId}/param
param name=barId${barId}/param
/result
Arguably, yes, and for a couple of reasons. Off the
top of my head I don't recall what will happen if the
param isn't found, though (or is null, etc.)
From reading the code it adds param= even if the param has no value,
which differs from the result of the OGNL code from which this was
translated...
...if there were a flag to control that I might use this...
...any struts committers reading this: If I provided a patch for an
extra specially named parameter like supressEmptyParameters that did
just what you'd expect, what are the chances that someone would commit it?
-Dale
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
