Re: [Springframework-developer] new 'RedirectViewResolver'

[Colin S. <col...@ex...>]

Seth Ladd wrote:

>>The whole point is that the view name still doesn't have any meaning to
>>the controller. It's a logical identifier as far as the controller is
>>concerned (the controller only deals in terms of names it gets as
>>properties), but this is one mechanism for the resolving machinery to
>>tell one target view from another.
>>    
>>
>
>Yes, good point.
>
>If I read you correctly, it sounds like the controller is making the
>decision to redirect or not.  You could set two view names into the
>controller, and give them meaningful names.  The business logic in the
>controller will chooses which view name to forward on to.  But the
>words "redirect" are now left out.  The two view names you give to the
>Controller are mapped normally.
>
>Something like:
>
>if (xxx) {
>  return new ModelAndView("viewA");
>} else if (XXX and YYY) {
>  return new ModelAndView("viewB");
>}
>
>where:
>
>viewA is JstlView
>viewB is RedirectView
>
>Not sure if that's cleaner, though.  It does remove any references to
>redirecting inside the controller (both RedirectView and redirect: are
>gone).
>
>  
>
No, the whole point is that the controller right now doesn't know what 
actual text of the view name is (it gets it from the success property 
for example, but it knows if it should return it as
   new ModelAndView(getSuccessView(),...
which is for a normal view (TilesJSTLView), or as
  new ModelAndView(new RedirectView(getSuccessView(), true))
for a redirect, which defeats the whole purpose of it not knowing the 
actual names (it's actually a bit worse than that, as in some cases it 
does have hard-coded view names which it returns as a redirectview, but 
let's suppose those could be brought in as properties instead, same as 
successview or formview). Now the actual text of the view names do 
contain enough info for the resolving machinery to know whether it's 
meant for Tiles (a simple name like "login") or as some sort of url (a 
name like "xxxxx.html"). Whatever, the actual names in this case don't 
matter, just that they are of different format, but the point is that 
while view chaining is supposed to be for these kinds of scenarios, for 
these kinds of scenarios the existing code doesn't work. None of the 
view resolvers can be used to make these kinds of decisions.

Colin