[Springframework-developer] RE: [Springframework-user] chain ViewResolvers?

[Alef A. <al...@jt...>]

Although I think this is a very useful addition, this should be =
documented
as a somewhat non-backward-compatible change, shouldn't it.

A co-worker of mine recently sublcassed one of the viewresolvers and
implemented the controller interface. He returned=20

  new ModelAndView(super.resolveView("whateverString"));

Although the approach may seem odd, it worked quite well. It won't =
anymore
with 1.0.2. Besides the controller / viewrsesolver now being picked up =
as a
viewresolver as well, the changed signature (return value) also affects =
it
(null ModelAndViews are not supported).

Two other questions:=20

1) Ordering is determined using the normal procedures with
OrderComparator/Ordered? So ViewResolver now extends Ordered?
=20
2) The behavior or the resolveView() method is not really clear anymore.
ViewResolver themselves are supposed to decide what they are returning,
either a View object that might have a non-existent underlying resource, =
or
null, also indicating a non-existent resource. Although probably not
feasible, it would be nice the get the behavior of all the viewresolvers =
in
line...

Comments?

I'll update the reference documentation as soon as things are cleared =
out...

Alef



> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On Behalf Of
> j=FCrgen h=F6ller [werk3AT]
> Sent: Tuesday, May 04, 2004 10:59 AM
> To: spr...@li...
> Subject: Re: [Springframework-user] chain ViewResolvers?
>=20
> This turned out so straightforward to do that I've just finished it -
> already committed to CVS :-)
>=20
> Juergen
>=20
>=20
> ________________________________
>=20
> Von: spr...@li... im Auftrag von
> j=FCrgen h=F6ller [werk3AT]
> Gesendet: Di 04.05.2004 08:01
> An: spr...@li...
> Betreff: Re: [Springframework-user] chain ViewResolvers?
>=20
>=20
>=20
> I see the point in having multiple ViewResolvers, so I'm inclined to
> change this for 1.0.2. In terms of DispatcherServlet bean definitions,
> this would mean checking for ViewResolver implementations rather than =
a
> bean with name "viewResolver", but that would be perfectly backward-
> compatible.
>=20
> The only semantic change that's necessary is the return value of
> ViewResolver's resolveViewName method: It should return null if not =
found,
> just throwing an exception when there was a problem creating an actual
> view.  The current implementations either throw
> NoSuchBeanDefinitionException if not found (like XmlViewResolver), or
> always return a View object even if there's no underlying resource =
(like
> InternalResourceViewResolver).
>=20
> So you can't use InternalResourceViewResolver as your first =
ViewResolver,
> as it will always return a View object - by its very nature. On the =
other
> hand, InternalResourceViewResolver will be a typical fallback resolver
> anyway, with an XmlViewResolver or ResourceBundleViewResolver put in
> front.
>=20
> So what we could do is to refine the "resolveViewName" semantics to =
allow
> for a null return value if not found, if the ViewResolver wants to =
support
> resolver chaining. As this is not a requirement, backward =
compatibility
> won't be broken. We could then change XmlViewResolver and
> ResourceBundleViewResolver to return null if no bean with the view =
name
> found. Of course, DispatcherServlet will have to throw a "view not
> resolvable" exception if all ViewResolvers returned null.
>=20
> What do you think? As this is easy enough to implement, I might go =
ahead
> this evening if we agree on the change.
>=20
> Juergen
>=20
>=20
> ________________________________
>=20
> Von: spr...@li... im Auftrag von =
Seth
> Ladd
> Gesendet: Di 04.05.2004 03:50
> An: spr...@li...
> Betreff: [Springframework-user] chain ViewResolvers?
>=20
>=20
>=20
> Hello,
>=20
> I saw an email here or on the forums asking if there was a reason for =
a
> single ViewResolver.  I, too, would like to be able to define multiple
> ViewResolvers and chain them together.  Most of the time, I would use
> the simple InternalResourceViewResolver.  For some views, though, I =
need
> more freeform creation and would like XmlViewResolver.  Being able to
> chain these together would give me the best of both worlds.  Less
> configuration is always a good thing.
>=20
> Thanks very much!
> Seth
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle =
10g.
> Take an Oracle 10g class now, and we'll give you the exam FREE.
> http://ads.osdn.com/?ad_id149&alloc_id=8166&op=3Dclick
> _______________________________________________
> Springframework-user mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-user
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle =
10g.
> Take an Oracle 10g class now, and we'll give you the exam FREE.
> http://ads.osdn.com/?ad_id149&alloc_id=8166&op=3Dick
> _______________________________________________
> Springframework-user mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-user
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle =
10g.
> Take an Oracle 10g class now, and we'll give you the exam FREE.
> http://ads.osdn.com/?ad_id149&alloc_id=8166&op=3Dick
> _______________________________________________
> Springframework-user mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-user