Re: [Springframework-developer] chain ViewResolvers?

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

Already committed - the new DispatcherServlet bean property is called =
"detectAllViewResolvers", default is true. If you're doing obscure =
things with ViewResolvers, simply turn "detectAllViewResolvers" off ;-)
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Alef Arendsen
Gesendet: Di 04.05.2004 18:46
An: spr...@li...
Betreff: RE: [Springframework-developer] chain ViewResolvers?

> 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.

Same here :(

> 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.

I like this (also the default "true" value, as long as we mention it in =
the
rel.notes like you're saying)! It should however be removed again in 1.1
IMHO, no workarounds please that give users the ability to abuse Spring =
in
obscure manners ;-). Maybe include a task in JIRA or something just so =
we
won't forget?

> 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.

You're right. It'll be mentioned in the changelog and maybe we could put
things in the release notes alongside the entry about the
allowMultipleViewREsolvers property...

> 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.
Ok, the allowMultipleViewResolvers property it is then!

-aa

>
> 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).
>
> 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...
>
> >
> > Juergen
> >
> >
> > -----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?
> >
> >
> > 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
> >
> >   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:
> >
> > 1) Ordering is determined using the normal procedures with
> > OrderComparator/Ordered? So ViewResolver now extends Ordered?
> >
> > 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?
> > >
> > > 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
> >
> >
> >
> > -------------------------------------------------------
> > 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.
> > 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.
> 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.
> 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.
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