Menu
▾
▴
springframework-developer
|
From: <jue...@we...> - 2004-05-04 11:49:36
|
Alef, you've got some valid points there.
resolveView's return value should not be too relevant: It would have =
thrown a NoSuchBeanDefinitionException before (in case of =
XmlViewResolver or ResourceBundleViewResolver); now DispatcherServlet =
will throw a corresponding ServletException if it gets a null value from =
all resolvers. This will also happen if ModelAndView contains neither a =
view name nor a View object, so I don't see misbehavior in that =
particular case.
An important point is that all ViewResolver implementations will now be =
considered ViewResolvers for the containing DispatcherServlet. This =
shouldn't affect 99.9% of all applications, as there's hardly any use =
case for further ViewResolvers in the context. The Controller that =
implements ViewResolver sure seems odd, but unfortunately such things =
are valid in current Spring. This is a major issue that I didn't =
consider - argh, my over-eagerness ;-(
ad 1) A ViewResolver implementation can implement Ordered. It's not =
required in the interface. (Neither is it for HandlerMappings etc).
ad 2) Well, there actually is a difference: resolveViewName is supposed =
to return null if there's no view *definition*. An exception should just =
get thrown if an existing view definition cannot be turned into a View =
object. UrlBasedViewResolvers do not work with view definitions but =
directly create a View object from the view name, therefore they will =
never return null.
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.)
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. Unfortunately, the resolveViewName =
return value is still relevant: We should be able to discriminate =
between "no view definition found" (-> check further ViewResolvers) and =
"could not create View object" (-> throw immediately) here...
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=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
-------------------------------------------------------
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
|
|
From: Alef A. <al...@jt...> - 2004-05-04 14:06:54
|
> 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
|
|
From: Seth L. <se...@eh...> - 2004-05-04 18:33:12
|
>>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! Just catching up on the discussion (the problem of living so far away is that my day is your night :). I'm curious why you think a ChainedViewResolver would be inconsistent. I view it as a new feature, not as breaking a pattern. It certainly seems the most simple (maintains 1 viewresolver for the servlet, allows for explicit ordering by definition of the chain, doesn't change any semantics on return variables, etc). Also, we can always add ChainedHandlerMapping. I'm not arguing, and I'm very pleased to see multiple viewresolvers now able to be specified (although still curious as to how to order, but will check that out shortly). Just wondering what the thought process is from those who know Spring better than I. :) Thanks! Seth |
|
From: Alef A. <al...@jt...> - 2004-05-04 19:35:40
|
> Just catching up on the discussion (the problem of living so far away = is > that my day is your night :). Hmmm, must have pressed the wrong button, accidentally moving the = discussion to the dev list... > I'm curious why you think a ChainedViewResolver would be inconsistent. > I view it as a new feature, not as breaking a pattern. It certainly > seems the most simple (maintains 1 viewresolver for the servlet, = allows > for explicit ordering by definition of the chain, doesn't change any > semantics on return variables, etc). Also, we can always add > ChainedHandlerMapping. Hmmm, just an opinion I guess. Defining a chain in a ChainedViewResolver = or ChainedHandlerMapping doesn't have any real value over the definition of such HandlerMappings and ViewResolvers directly, Ordering is already possible, etcetera. I think all of us aren't really fond of providing = stuff that doesn't have any added value. The main reason why J=FCrgen proposed the ChainedViewResolver was = basically to maintain backward-compatibility, but that's been fixed now. You can = tweak the DispatcherServlet with a property enabling or disabling multiple viewresolvers. I saw you figured out the ordering already? Alef |
|
From: Timo V. <sic...@gm...> - 2004-05-06 12:36:44
|
Hello,
this might be slightly off-topic.
I used to work with the InternalResourceViewResolver for convenience
until I needed support for additional View classes (redirects in my
case). However, I did not want to map every view explicitly, as in the
countries and petclinic samples, and came up with another idea: I wrote
a simple DelegatingViewResolver which maps prefixes to ViewResolvers.
The configuration looks like this:
<bean id="defaultViewResolver"
class="org.springframework.web.servlet.view.InternalResourceViewResolver">
<property
name="viewClass"><value>org.springframework.web.servlet.view.JstlView</value></property>
<property name="prefix"><value>/WEB-INF/intranet/</value></property>
<property name="suffix"><value>.jspx</value></property>
</bean>
<bean id="redirectViewResolver"
class="de.tcv.da.customerservice.util.RedirectViewResolver"/>
<bean id="viewResolver"
class="de.tcv.da.customerservice.util.DelegatingViewResolver">
<property name="defaultResolver">
<ref local="defaultViewResolver"/>
</property>
<property name="prefixMappings">
<map>
<entry key="redirect"><ref local="redirectViewResolver"/></entry>
</map>
</property>
</bean>
Now I can have view names like "redirect:http://www.google.com",
"redirect:index.page", and "showCustomer.page" without sacrificing the
convenience of the InternalResourceViewResolver for my jspx files.
This could be easily extended to multiple InternalResourceViewResolver
instances to support more View classes, yielding view names like
"xls:customer", "pdf:customer", "jsp:index", etc. The separator is
configurable.
If it's any useful to others I can contribute my DelegatingViewResolver
and RedirectViewResolver sources.
Regards,
Timo
|
