Menu
▾
▴
springframework-developer
|
From: Colin S. <col...@ex...> - 2004-07-28 18:37:15
|
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. Colin |
|
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 |
|
From: Colin S. <col...@ex...> - 2004-07-29 00:56:48
|
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 > > |
|
From: Seth L. <set...@gm...> - 2004-07-29 01:29:26
|
> 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).
Seth
|
|
From: Colin S. <col...@ex...> - 2004-07-29 02:46:35
|
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
|
|
From: Seth L. <set...@gm...> - 2004-07-29 08:55:07
|
> 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))
Right, we definitely don't want the controller knowing the view names.
I meant to merely suggest that the controller has two properties, one
successView and another of business meaning (call it leaveView). My
previous example would change to:
if (XXX) {
return new ModelAndView(getSuccessView());
} else if (XXX and YYY) {
return new ModelAndView(getLeaveView());
}
But I see exactly what you are saying...
Seth
|
