Re: [Springframework-developer] new 'RedirectViewResolver'

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

Seth Ladd wrote:

>On Wed, 28 Jul 2004 14:35:56 -0400, Colin Sampaleanu <col...@ex...> wrote:
>  
>
>>I'm working with an app (original source is not by me) that currently
>>has some pretty nasty view handling. It uses TilesJstlView, but for some
>>view properties the controller is actually aware that the view names
>>represent a need to redirect, and in those cases the controller returns
>>a new RedirectView it creates itself. I think this is pretty unclean.
>>Does anybody think it's worth having a new standard view resolver of
>>some sort that can be chained in front of other resolvers (such as in
>>this case TilesJstlViewResolver), and can recognize view names which
>>include a prefix meaning this is a redirect view? I.e.
>>RedirectViewResolver would recognize view names of the nature
>>  redirect:/some/external/path
>>and use a redirectView in that case? If they don't have the prefix, it
>>doesn't do anything and lets the next resolver get a whack at it.
>>
>>Another standard view resolver I could see being handy is a regex view
>>resolver, where there is a composite pattern being used. The resolver
>>has 1 to n other view resolvers registered with it, and for each one, a
>>regex. If there is a regex match, then it delegates to the view resoler
>>or chain of view resolvers set up for that regex.
>>    
>>
>
>Though I'm not in favor of a view name that has special meaning (I
>think view names should just be logical identifies), I do like the
>idea of a regex view resolver.
>  
>
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.

>I've also thought that a view resolver that can look at the Accept:
>header sent by the client would be useful sometimes.  It would be nice
>to do some content negotiation at the view resolving layer.  The view
>objects themselves would implement ContentNegotiable, and expose a
>public Map accepts() method (or some sort) that returns a map of
>content-type and the quality index.  The view name returned by the
>client is then used to find all views that match, and finds the best
>content type to serve the client.  Unfortunately, the ViewResolver
>interface doesn't know a thing about the HttpServletRequest (needed to
>get the Accept: headers).
>
>Seth
>  
>