|
From: Seth L. <set...@gm...> - 2004-07-29 00:15:23
|
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. 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 |