Re: [struts] Thanks! Works also with redirect actions...

[Dale Newfield <Da...@Newfield.org>]

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="actionName">mySuccess</param>
   <param name="fooId">${fooId}</param>
   <param name="barId">${barId}</param>
</result>

-Dale

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

ServletRedirect vs ServletActionRedirect (was: [struts] Thanks! Works also with redirect actions...)

[Gary Affonso <gl...@greywether.com>]

Dale Newfield 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...
> 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? 

I don't use it (yet), but I think the intent here is to avoid the 
developer putting the ".action" string on the end of the urls you're 
redirecting to.  Or, for that matter, specifying the any part of the url 
fragment in detail at all.  You specify what goes into the URL and then 
let the ActionMapper generate it.

If you don't do that and specify the url fragment along with the 
".action" suffix then any time you change the mapping (say you want your 
actions to have ".do" on the end instead of ".action") then you have to 
go through and fix all your redirect urls.

Going through the RedirectAction result type shields you a bit from that 
change.  You don't specify the actual url (you let the ActionMapper 
generate it) so when the configuration of the ActionMapper changes your 
redirect Urls automatically reflect that change.

The above example (changing ".action" to ".do") is probably not a very 
convincing example, when would you ever do that?

But you can get really fancy with the ActionMapper and start doing stuff 
like SEO friendly URL recognition (and generation) to eliminate the 
"?key=value search engines like.

That's something we *are* looking at doing and, I suspect, that we'll 
benefit from not having written our redirects as hardcoded url fragments.

- Gary

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

Re: [struts] Thanks! Works also with redirect actions...

[Dale Newfield <da...@newfield.org>]

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-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

Re: [struts] Thanks! Works also with redirect actions...

[martinib <ma...@gmail.com>]

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-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@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-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

Re: [struts] Thanks! Works also with redirect actions...

[Dale Newfield <Da...@Newfield.org>]

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-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

Re: [struts] Thanks! Works also with redirect actions...

[Dave Newton <ne...@yahoo.com>]

--- Dale Newfield <Da...@Newfield.org> 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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

Re: [struts] Thanks! Works also with redirect actions...

[Dale Newfield <Da...@Newfield.org>]

Dave Newton wrote:
>> <result name="success" type="redirectAction">
>>    <param name="actionName">mySuccess</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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

Re: [struts] Thanks! Works also with redirect actions...

[Dave Newton <ne...@yahoo.com>]

--- Dale Newfield <Da...@Newfield.org> 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="actionName">mySuccess</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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org