Re: [Springframework-developer] chain ViewResolvers?

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

I'm a bit torn between seeing the value of this feature and the issue =
with now treating all ViewResolver beans in the context as relevant for =
the DispatcherServlet. I do believe that 99.9% of all applications are =
not affected by this, but some rather obscure usages might. However, it =
should be easy to rewrite such obscure usages to not rely on separate =
ViewResolvers.

An option to easily allow backward compatibility would be a =
DispatcherServlet setting "allowMultipleViewResolvers", falling back to =
a single "viewResolver" bean if turned off. Question is: Should the =
default be "true" or "false"? I guess "true" would be fine, as long as =
we document that in the release notes. In case of obscure ViewResolver =
usage, simply specify "false" there.

Regarding ViewResolver interface semantics: They actually were unclear =
before; the javadocs didn't exactly state when to throw an exception. I =
don't think that defining specific handling for null would cause =
compatibility headaches. I rather consider it an improvement to actually =
specify the expected behavior here.

I completely agree that it would be much nicer to have multiple =
ViewResolver bean definitions rather than a separate ChainedViewResolver =
that in turn delegates to multiple ViewResolvers... I guess an explicit =
"allowMultipleViewResolvers" setting is a much better solution than a =
ChainedViewResolver.

Juergen

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Alef Arendsen
Sent: Tuesday, May 04, 2004 4:10 PM
To: spr...@li...
Subject: RE: [Springframework-developer] RE: [Springframework-user]
chain ViewResolvers?

> This is a major issue that I didn't consider - argh, my
> over-eagerness ;-(
No problem, without your eagerness, we wouldn't have come this far =
probably
;-).

> ad 1) A ViewResolver implementation can implement Ordered. <snip>
> ad 2) Well, there actually is a difference <snip>
Ok, perfect.

> Of course, the change would need to be documented. It's also something
> that we could potentially delay till 1.1, if we consider the change =
too
> much for a point release. (Although our point releases are actually
> Hibernate/Tomcat-style point releases that introduce minor new
> functionality and internal reworkings, rather than plain bugfix =
releases.)
It's not a question of whether or not we want to add functionality and
rework stuff IMO. One thing we have to consider at all times is that we =
have
existing users and we don't know what they're using and how they're =
using
it.

> That said, we could also stick to a single "viewResolver" bean and =
offer a
> "ChainedViewResolver" adapter that takes a List of further =
ViewResolvers
> that it delegates to.
Hmmm, the ChainedViewResolver would be inconsistent with the possibility =
of
having multiple UrlHandlerMappings, which are NOT contained by a
ChainedHandlerMapping or something like that... Once you get used to the =
way
beans are defined in the WebApplicationContext it's really intuitive, so =
we
shouldn't go and introduce concepts like this IMO.

Also, I don't like workarounds or inconsistencies to be able to include
something that might otherwise result in a non-backward-compability... =
So
AFAIC the ChainedViewResolver is a no-go... This would mean we can't add =
the
multiple viewresolvers... But I don't like that either!

Provided that we put a big warning on the website mentioning this issue, =
I'm
ok with the stuff that's in the CVS now (multiple resolvers, all at the =
root
of the WebAppCtx).=20

Alef

p.s. sorry to be picky about this, but I already got a couple of =
compliments
from people about release management being pretty good, I want to keep =
it
that way...

>=20
> Juergen
>=20
>=20
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...]On =
Behalf
> Of Alef Arendsen
> Sent: Tuesday, May 04, 2004 12:16 PM
> To: spr...@li...
> Subject: [Springframework-developer] RE: [Springframework-user] chain
> ViewResolvers?
>=20
>=20
> Although I think this is a very useful addition, this should be =
documented
> as a somewhat non-backward-compatible change, shouldn't it.
>=20
> A co-worker of mine recently sublcassed one of the viewresolvers and
> implemented the controller interface. He returned
>=20
>   new ModelAndView(super.resolveView("whateverString"));
>=20
> 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).
>=20
> 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...
>=20
> Comments?
>=20
> I'll update the reference documentation as soon as things are cleared
> out...
>=20
> Alef
>=20
>=20
>=20
> > -----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?
> >
> > This turned out so straightforward to do that I've just finished it =
-
> > already committed to CVS :-)
> >
> > Juergen
> >
> >
> > ________________________________
> >
> > 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?
> >
> >
> >
> > 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.
> >
> > 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).
> >
> > 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.
> >
> > 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.
> >
> > What do you think? As this is easy enough to implement, I might go =
ahead
> > this evening if we agree on the change.
> >
> > Juergen
> >
> >
> > ________________________________
> >
> > Von: spr...@li... im Auftrag von
> Seth
> > Ladd
> > Gesendet: Di 04.05.2004 03:50
> > An: spr...@li...
> > Betreff: [Springframework-user] chain ViewResolvers?
> >
> >
> >
> > Hello,
> >
> > 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.
> >
> > Thanks very much!
> > Seth
> >
> >
> >
> > -------------------------------------------------------
> > 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
> >
> >
> >
> >
> > -------------------------------------------------------
> > 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
> >
> >
> >
> >
> > -------------------------------------------------------
> > 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
> -------------------------------------------------------
> 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-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=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-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

-------------------------------------------------------
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.=20
http://ads.osdn.com/?ad_id149&alloc_id=8166&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer