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