That was the main reason. Most people don't want to bother (or often
even know about) chaining view resolvers. So since they couldn't rely on
the [Xml|ResourceBundle]ViewResolver being in use and taking care of
this, there was a decent amount of controller code out there that just
did manual instantionations of RedirectView. I always found that pretty
nasty and unclean. A controller just shouldn't know about that kind of
thing.
Colin
Darren Davison wrote:
>Hi all,
>
>The "redirect:" prefix that was added as a feature last year enables
>controllers to remain ignorant of the redirect since the String value
>containing the prefix can be injected into the controller bean. That much I
>understand.
>
>What I'm wondering is whether there was another benefit, or problem solved, by
>taking this route? It seems to be a natural limitation of the choice of
>ViewResolver that the problem actually solves.. if the app is using a
>UrlBasedViewResolver or subclass, the redirect: prefix is needed.
>
>However, if the app defined an [Xml|ResourceBundle]ViewResolver and ordered it
>first, then that could be used to resolve redirect views, falling back to the
>UrlBasedViewResolver for everything else. It looks like this would mitigate
>the need for the special handling of view name prefixes.
>
>I can't see anything in the discussions or JIRA issues from around the time
>this feature was added eluding to this other than a comment I made myself [1],
>so am I missing something here?
>
>[1] http://opensource2.atlassian.com/projects/spring/browse/SPR-387
>
>Regards,
>
>
|
