You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Gunnar Hillert <gu...@hillert.com> on 2007/11/08 00:02:26 UTC

Thanks! Works also with redirect actions...

Hi,

Thanks for your helpful post! Interestingly, this also works with redirect
actions. Since I have not seen any examples anywhere out there, I thought I
also post an example for them:

            <result name="success" type="redirectAction">
                mySuccess?fooId=${fooId}${bartId ? "&amp;barId=" + barId :
""}
            </result>

Cheers,

Gunnar



Gary Affonso wrote:
> 
> I knew I had done this before, I just found the code.
> 
> Your redirect needs to look something like...
> 
> <result name="success" type="redirect">
>    
>      myAction.action${foo ? '?foo=' + foo : ''}
>    
> </result>
> 
> Note that I'm pretty sure your OGNL lookups are not going to get 
> url-escaped.
> 
> The above assumes that "foo" is a property of the Action and available 
> to OGNL (a getter).  If foo lives somewhere else (like in the session, 
> for instance) then you'll need to do a little more work to write the 
> proper ognl reference.
> 
> Anyway, hope that helps.  I think the above is (mostly) right this time.
> :-)
> 
> - Gary
> 
> 
> Gary Affonso wrote:
>> I think you already know this, but in case you don't...  When you 
>> specify the action to redirect to, you have access to the OGNL stack.
>> 
>> So your redirect may look something like this..
>> 
>> <result name="success"type="redirect">
>>   myAction.action?param=${paramValue}
>> </result>
>> 
>> I think what you're asking is, if "param" has no value, you don't want 
>> to see *anything* in the url.  Neither the key nor the value of the 
>> key/value pair.  Right?
>> 
>> So it should be just a matter of coming up with an OGNL expression that 
>> tests for null before inserting either part of the key/value pair.
>> 
>> Something like:
>> 
>>   myAction.action?${paramValue ? '' : 'param=' + paramValue}
>> 
>> Note, that's *totally* off-the-cuff.  I know OGNL does have the ternary 
>> operator ( condition ? e2 : e3) but the string quoting, null checks, 
>> ${}, string concatenation, etc. is probably all be wrong in that line 
>> above. :-)
>> 
>> The point is that I think all you need to do is be a little more 
>> sophisticated about the OGNL string.  You just gotta go learn a bit more 
>> about OGNL.
>> 
>> The OGNL language reference (at least the one I know about) is here:
>> 
>>   http://www.ognl.org/2.6.9/Documentation/html/LanguageGuide/index.html
>> 
>> - Gary
>> 
>> Gunnar Hillert wrote:
>>> Hi,
>>>
>>> A typical requirement in my webapps is to "redirect" to result pages 
>>> after
>>> form submission.
>>> This is quite nicely described here:
>>> http://www.vitarara.org/cms/struts_2_cookbook/post_and_redirect
>>>
>>> This works great but here is my question:
>>>
>>> Is there a way to dynamically create parameters? For instance, I have
>>> use
>>> cases where I don't have to provide all parameters in my redirects at
>>> all
>>> times. Thus, if the value of variable foo is null in my action I don't 
>>> want
>>> to use the variable in my redirect. I hate to see
>>> .../myaction.action?foo=&bar=1 in my urls.
>>>
>>> Is there anything in Struts that would allow this? E.g. some additional
>>> attribute on the param element would be nice ${foo}
>>>
>>> Or do I have to create my own "custom" result-type?
>>>
>>> Thanks!
>>>
>>> Gunnar Hillert
>> 
>> 
>> ---------------------------------------------------------------------
>> 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
> 
> 
> 

-- 
View this message in context: http://www.nabble.com/Redirects---Dynamic-Parameters-tf4758978.html#a13638069
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


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

Posted by 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...

Posted by 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...

Posted by 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...

Posted by 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...

Posted by 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...

Posted by 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...

Posted by 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


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

Posted by 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


Re: Thanks! Works also with redirect actions...

Posted by Gary Affonso <gl...@greywether.com>.
Gunnar Hillert wrote:
> Thanks for your helpful post!

You bet.

> Interestingly, this also works with redirect
> actions. Since I have not seen any examples anywhere out there, I thought I
> also post an example for them:
> 
>             <result name="success" type="redirectAction">
>                 mySuccess?fooId=${fooId}${bartId ? "&amp;barId=" + barId :
> ""}
>             </result>

Right.  As Dave noted, all of the result types (that I now about, 
anyway) support OGNL parsing of the parameters.

- Gary

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


Re: Thanks! Works also with redirect actions...

Posted by Dave Newton <ne...@yahoo.com>.
Most (all?) of the built-in result types parse OGNL in
the "location" param, although you can turn off that
functionality via the "parse" param.

d.

--- Gunnar Hillert <gu...@hillert.com> wrote:

> 
> Hi,
> 
> Thanks for your helpful post! Interestingly, this
> also works with redirect
> actions. Since I have not seen any examples anywhere
> out there, I thought I
> also post an example for them:
> 
>             <result name="success"
> type="redirectAction">
>                 mySuccess?fooId=${fooId}${bartId ?
> "&amp;barId=" + barId :
> ""}
>             </result>
> 
> Cheers,
> 
> Gunnar
> 
> 
> 
> Gary Affonso wrote:
> > 
> > I knew I had done this before, I just found the
> code.
> > 
> > Your redirect needs to look something like...
> > 
> > <result name="success" type="redirect">
> >    
> >      myAction.action${foo ? '?foo=' + foo : ''}
> >    
> > </result>
> > 
> > Note that I'm pretty sure your OGNL lookups are
> not going to get 
> > url-escaped.
> > 
> > The above assumes that "foo" is a property of the
> Action and available 
> > to OGNL (a getter).  If foo lives somewhere else
> (like in the session, 
> > for instance) then you'll need to do a little more
> work to write the 
> > proper ognl reference.
> > 
> > Anyway, hope that helps.  I think the above is
> (mostly) right this time.
> > :-)
> > 
> > - Gary
> > 
> > 
> > Gary Affonso wrote:
> >> I think you already know this, but in case you
> don't...  When you 
> >> specify the action to redirect to, you have
> access to the OGNL stack.
> >> 
> >> So your redirect may look something like this..
> >> 
> >> <result name="success"type="redirect">
> >>   myAction.action?param=${paramValue}
> >> </result>
> >> 
> >> I think what you're asking is, if "param" has no
> value, you don't want 
> >> to see *anything* in the url.  Neither the key
> nor the value of the 
> >> key/value pair.  Right?
> >> 
> >> So it should be just a matter of coming up with
> an OGNL expression that 
> >> tests for null before inserting either part of
> the key/value pair.
> >> 
> >> Something like:
> >> 
> >>   myAction.action?${paramValue ? '' : 'param=' +
> paramValue}
> >> 
> >> Note, that's *totally* off-the-cuff.  I know OGNL
> does have the ternary 
> >> operator ( condition ? e2 : e3) but the string
> quoting, null checks, 
> >> ${}, string concatenation, etc. is probably all
> be wrong in that line 
> >> above. :-)
> >> 
> >> The point is that I think all you need to do is
> be a little more 
> >> sophisticated about the OGNL string.  You just
> gotta go learn a bit more 
> >> about OGNL.
> >> 
> >> The OGNL language reference (at least the one I
> know about) is here:
> >> 
> >>  
>
http://www.ognl.org/2.6.9/Documentation/html/LanguageGuide/index.html
> >> 
> >> - Gary
> >> 
> >> Gunnar Hillert wrote:
> >>> Hi,
> >>>
> >>> A typical requirement in my webapps is to
> "redirect" to result pages 
> >>> after
> >>> form submission.
> >>> This is quite nicely described here:
> >>>
>
http://www.vitarara.org/cms/struts_2_cookbook/post_and_redirect
> >>>
> >>> This works great but here is my question:
> >>>
> >>> Is there a way to dynamically create parameters?
> For instance, I have
> >>> use
> >>> cases where I don't have to provide all
> parameters in my redirects at
> >>> all
> >>> times. Thus, if the value of variable foo is
> null in my action I don't 
> >>> want
> >>> to use the variable in my redirect. I hate to
> see
> >>> .../myaction.action?foo=&bar=1 in my urls.
> >>>
> >>> Is there anything in Struts that would allow
> this? E.g. some additional
> >>> attribute on the param element would be nice
> ${foo}
> >>>
> >>> Or do I have to create my own "custom"
> result-type?
> >>>
> >>> Thanks!
> >>>
> >>> Gunnar Hillert
> >> 
> >> 
> >>
>
---------------------------------------------------------------------
> >> 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
> > 
> > 
> > 
> 
> -- 
> View this message in context:
>
http://www.nabble.com/Redirects---Dynamic-Parameters-tf4758978.html#a13638069
> 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
> 
> 


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