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