|
From: <jue...@we...> - 2004-12-06 18:47:23
|
Rob,
=20
First of all, thanks for the suggestions!
=20
The problem is that the Velocity tool instances cannot be shared if they =
are supposed to respect the locale for the current request, because they =
need to keep a reference to the current locale. Some of them, like =
LinkTool, aren't even thread-safe in their base implementation.
=20
That's why we currently create new instances for each render process, =
under the specific model attribute names. We couldn't pass those in as =
existing instances to the Velocity context, at least not in general.
=20
What we could do beyond the current support is to allow for specifying =
model attribute / tool class pairs. A single "toolAttributes" property =
of type java.util.Properties should be sufficient for this, with the =
model attribute name as key and the tool class name as value. I've just =
added such a property to VelocityView, which works nicely with MathTool =
and similarly general tools.
=20
For locale-aware versions of standard Velocity tools, you need to =
subclass each and every one of them. I currently prefer to offer all of =
those as special "xxxToolAttribute" properties in VelocityView. There =
aren't any other than DateTool and NumberTool anyway in Velocity Tools =
1.1 anyway, and for any custom locale-aware tools it should be feasible =
to subclass VelocityView accordingly.
=20
Static attribute values can already be exposed in a generic way, via =
AbstractView's "attributes" and "attributesCSV" properties. This should =
work for VelocityViews too, so I don't see a need for extra facilities =
on VelocityView that just serve to expose such values too.
=20
On this occasion, I've just added a VelocityToolboxView subclass that =
allows a "toolboxConfigLocation" to be specified, automatically loading =
a Velocity Tools toolbox XML file and all defined tools in the specified =
scopes. ViewTools like LinkTool are properly supported there (they =
aren't in plain VelocityView), and values can be defined ther etoo.
=20
VelocityToolboxView also adds a check for tools specified as =
"toolAttributes", detecting ViewTools and initializing them with an =
appopriate ViewContext. It creates a special ChainedContext for this, =
passing it to ViewTool "init" methods if necessary. So such tools can be =
defined on VelocityView itself too, as alternative to a Velocity Tools =
toolbox XML file.
=20
VelocityToolboxView is a separate class mainly to avoid a required =
dependency on the view package of Velocity Tools in VelocityView itself. =
VelocityView has to keep working with plain Velocity in the classpath. =
The DateTool and NumberTool dependencies in VelocityView are purely =
optional, so don't break this rule.=20
=20
Juergen
=20
________________________________
Von: spr...@li... im Auftrag von Rob =
Butler
Gesendet: Mo 06.12.2004 16:08
An: spr...@li...
Betreff: Re: [Springframework-user] Velocity Tools and Spring MVC
Shouldn't it be possible to expose additional helpers
to velocity via configuration instead of needing to
sub-class VelocityView?
Couldn't VelocityView & VelocityViewResolver have
methods similar to:
setBooleanTools(Map tools);
setNumberTools(Map tools);
setStringTools(Map tools);
setObjectTools(Map tools);
(Better names welcome!)
Then additional tools can be made available to every
velocity template via VelocityViewResolver
configuration, much like format, date and number tools
are now. The existing method of exposing format, date
and number tools could even be deprecated since the
new methods above could be used to do the same.
By allowing these tools to be set using the config
file, we can take advantage of Springs bean post
processors to do things like:
<prop key=3D"debug" value=3D"${debug}"/>
Which would allow the tempates to obtain data from the
same property file used by the rest of the
application.
Also, while the above is being done, i18n support in
velocity date/number tools is nice in spring because
the framework set's the locale. Could an interface
called VelocityLocaleAwareTool with a single method of
setLocale(Locale locale) be developed? Then any tool
which supports i18n could implement this interface.
Spring could check if the tools in the Object based
tools support the interface, and if so automatically
set the locale. The existing local support for the
number and date tool could be re-factored to take
advantage of the new interface as well.
This all would make adding tools to Velocity a lot
easier, and add standardized support for i18n aware
tools in spring.
Later
Rob
--- j=FCrgen h=F6ller [werk3AT]
<jue...@we...> wrote:
> I've removed the deprecation from
> "exposeHelpers(Context, HttpServletRequest)", as
> there is a valid use case: instantiating further
> Velocity tools that need a Velocity Context.
>=20
> I've also added an overloaded "exposeHelpers"
> variant that takes VelocityContext,
> HttpServletRequest and HttpServletResponse: mainly
> for creating subclasses of ViewTool that depend on a
> Velocity ViewContext, with ChainedContext being the
> only out-of-the-box implementation and in turn
> depending on HttpServletRequest and
> HttpServletResponse.
>=20
> Finally, I've added an overloaded
> "createVelocityContext" method that takes model Map,
> HttpServletRequest and HttpServletResponse: You
> could potentially create a ChainedContext instance
> there, if you wanted request attributes etc to be
> visible in the Velocity template mode. Tools that
> depend on ViewContext could then simply take the
> passed-in Velocity Context as-is, passing it into
> "init".
>=20
> Juergen
>=20
>
> ________________________________
>
> Von:
> spr...@li... im
> Auftrag von Roberto Cosenza
> Gesendet: Mo 29.11.2004 09:12
> An: spr...@li...
> Betreff: Re: [Springframework-user] Velocity Tools
> and Spring MVC
>
>
>
> Huy wrote:
>
> > I tried this but I don't know how you get the
> reponse in the "new
> > ChainedContext(velocityContext, request, response,
> > getServletContext)". On another note,
> exposeHelpers(Context,
> > HttpServletResponse) is deprecated in favour of
> exposeHelpers(Map,
> > HttpServletRequest) so I was trying to use this,
> which I then ran into
> > problems getting velocityContext and response
> objects.
>
> You are right. I didn't notice that problem in the
> exposeHelpers. I will
> ask the Spring guys to fix it.
> In the meanwhile, you can do something like
>
> protected void renderMergedTemplateModel(
> Map model, HttpServletRequest request,
> HttpServletResponse
> response) throws Exception {
> Context velocityContext =3D new
> VelocityContext(model);
> ChainedContext chainedContext =3D new
> ChainedContext(velocityContext,
> request, response,
> getServletContext());
> LinkTool linkTool =3D new LinkTool();
> linkTool.init(chainedContext);
> model.put("link", linkTool);
>
> // call super , whith a model that contains the
> linkTool. It will be
> automatically put in the velocity context.
> renderMergedTemplateModel(mode, request,
> response);
> }
>
> >
> > Any other help would be great. It would be good if
> we could just use
> > the tools.xml from the Velocity tools probject to
> configure these things.
> >
> I don't think you can, imho. If I understood weel
> that works only if you
> have a velocity tool servlet, as explained in their
> (confusing) docs.
>
> > Regards,
> >
> > Huy
>
> rrier-grade messaging products.
>
>
>
>
>
-------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT
> Products from real users.
> Discover which products truly live up to the hype.
> Start reading now.
> http://productguide.itmanagersjournal.com/
> _______________________________________________
> Springframework-user mailing list
> Spr...@li...
>
https://lists.sourceforge.net/lists/listinfo/springframework-user
>
>
>
>
>
-------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT
> Products from real users.
> Discover which products truly live up to the hype.
> Start reading now.
> http://productguide.itmanagersjournal.com/
> _______________________________________________
> Springframework-user mailing list
> Spr...@li...
>
https://lists.sourceforge.net/lists/listinfo/springframework-user
>
=20
=20
__________________________________
Do you Yahoo!?
Yahoo! Mail - You care about security. So do we.
http://promotions.yahoo.com/new_mail
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
Springframework-user mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-user
|
|
From: <jue...@we...> - 2004-12-08 20:38:38
|
OK, I'll add an "attributes" property of type java.util.Properties and =
an "attributesMap" property of type java.util.Map to =
UrlBasedViewResolver. The first can be populated via <value> or <props>; =
the latter is meant to be populated via <map> but also allows specifying =
direct entries like <property =
name=3D"attributesMap[key1]"><value>myValue</value></property>.
=20
"attributesCSV" doesn't make too much sense on a ViewResolver, as it's =
really just meant for view definitions in properties file (read by =
ResourceBundleViewResolver). For this reason, I'm not keen on =
introducing it on UrlBasedViewResolver.
=20
Juergen
=20
________________________________
Von: spr...@li... im Auftrag von Rob =
Butler
Gesendet: Di 07.12.2004 20:44
An: spr...@li...
Betreff: Re: [Springframework-user] Velocity Tools and Spring MVC
Actually, things may not be as clear as I thought.
> > I understand your argument of allowing
> > Spring-managed placeholders; that's why I pointed
> > out the "attributes" support. AbstractView's
> > "attributes" and "attributesCSV" are indeed just
> > suitable for String values, but "attributesMap"
> > allows any Object as value: You could define inner
> > beans of type java.lang.Integer or the like there,
> > to get values of specific types. The problem of
> > getting special types for map values is not
> > restricted to VelocityView; it's the same for any
> > other type of Spring-defined bean, so needs a
> > generic solution.
Ok, I agree with everything above. But here's the
problem. I can add an attribute to a view, but if I
have 30 views in my application, and I want the same
property exposed to all 30 views, I then must define
30 view beans in my spring config (yuck!). There is
currently no way to set attributes in a view resolver
so that the attributes are added to all views created
by that resolver.
Can you add a setAttributes(Properties prop),
setAttributesMap(Map), and a setAttributesCSV(String)
method to the
org.springframework.web.servlet.view.UrlBasedViewResolver
class? This would then allow you to add properties to
the view resolver, so the properties are then
available in all views created by the resolver. Since
this is a base view resolver, the functionality would
be available to all other view technologies too, so it
is a generic solution.
Thanks.
Rob
=20
__________________________________
Do you Yahoo!?
Yahoo! Mail - 250MB free storage. Do more. Manage less.
http://info.mail.yahoo.com/mail_250
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
Springframework-user mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-user
|
|
From: Rob B. <cro...@ya...> - 2004-12-08 21:08:59
|
GREAT! Will this make it into 1.1.3? Thanks jürgen, your efforts are greatly appreciated. Rob --- jürgen höller [werk3AT] <jue...@we...> wrote: > OK, I'll add an "attributes" property of type > java.util.Properties and an "attributesMap" property > of type java.util.Map to UrlBasedViewResolver. The > first can be populated via <value> or <props>; the > latter is meant to be populated via <map> but also > allows specifying direct entries like <property > name="attributesMap[key1]"><value>myValue</value></property>. > > "attributesCSV" doesn't make too much sense on a > ViewResolver, as it's really just meant for view > definitions in properties file (read by > ResourceBundleViewResolver). For this reason, I'm > not keen on introducing it on UrlBasedViewResolver. > > Juergen > > > ________________________________ > > Von: > spr...@li... im > Auftrag von Rob Butler > Gesendet: Di 07.12.2004 20:44 > An: spr...@li... > Betreff: Re: [Springframework-user] Velocity Tools > and Spring MVC > > > > Actually, things may not be as clear as I thought. > > > > I understand your argument of allowing > > > Spring-managed placeholders; that's why I > pointed > > > out the "attributes" support. AbstractView's > > > "attributes" and "attributesCSV" are indeed just > > > suitable for String values, but "attributesMap" > > > allows any Object as value: You could define > inner > > > beans of type java.lang.Integer or the like > there, > > > to get values of specific types. The problem of > > > getting special types for map values is not > > > restricted to VelocityView; it's the same for > any > > > other type of Spring-defined bean, so needs a > > > generic solution. > > Ok, I agree with everything above. But here's the > problem. I can add an attribute to a view, but if I > have 30 views in my application, and I want the same > property exposed to all 30 views, I then must define > 30 view beans in my spring config (yuck!). There is > currently no way to set attributes in a view > resolver > so that the attributes are added to all views > created > by that resolver. > > Can you add a setAttributes(Properties prop), > setAttributesMap(Map), and a > setAttributesCSV(String) > method to the > org.springframework.web.servlet.view.UrlBasedViewResolver > class? This would then allow you to add properties > to > the view resolver, so the properties are then > available in all views created by the resolver. > Since > this is a base view resolver, the functionality > would > be available to all other view technologies too, so > it > is a generic solution. > > Thanks. > Rob > > > > __________________________________ > Do you Yahoo!? > Yahoo! Mail - 250MB free storage. Do more. Manage > less. > http://info.mail.yahoo.com/mail_250 > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT > Products from real users. > Discover which products truly live up to the hype. > Start reading now. > http://productguide.itmanagersjournal.com/ > _______________________________________________ > Springframework-user mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-user > > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT > Products from real users. > Discover which products truly live up to the hype. > Start reading now. > http://productguide.itmanagersjournal.com/ > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > __________________________________ Do you Yahoo!? All your favorites on one personal page Try My Yahoo! http://my.yahoo.com |
|
From: Roberto C. <rob...@in...> - 2004-12-15 12:06:42
|
Does'nt this method belong to a common superclass? It would be nice to have it on a ResourceBundleViewResolver, f.i. /Roberto j=FCrgen h=F6ller [werk3AT] wrote: >OK, I'll add an "attributes" property of type java.util.Properties and a= n "attributesMap" property of type java.util.Map to UrlBasedViewResolver.= The first can be populated via <value> or <props>; the latter is meant t= o be populated via <map> but also allows specifying direct entries like <= property name=3D"attributesMap[key1]"><value>myValue</value></property>. >=20 >"attributesCSV" doesn't make too much sense on a ViewResolver, as it's r= eally just meant for view definitions in properties file (read by Resourc= eBundleViewResolver). For this reason, I'm not keen on introducing it on = UrlBasedViewResolver. >=20 >Juergen >=20 > >____ > |