velocity-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gabriel Sidler <>
Subject Re: Velocity vmlibs
Date Thu, 16 May 2002 09:03:04 GMT
Warner Onstine wrote:

> ----- Original Message -----
> From: "Bill Boland" <>
> To: "'Velocity Developers List'" <>
> Sent: Wednesday, May 15, 2002 7:25 PM
> Subject: RE: Velocity vmlibs
>>I've been thinking along the same lines. I have struggled with JSPs for
>>a couple of years and finally got to use Velocity on a web project
>>recently. It made all the difference.
>>Opening up a "candy store" of libraries to entice others is a nice way
>>to get more visibility and appeal for your project as well as watching
>>the chain reaction when you collect enough to make a core library like
>>the JSTL is doing with taglibs.
> Pretty much what I was thinking (I'm tired of everyone talking about Struts
> and JSP and how cool they are together ;-).
>>The velocity-tools (at
>> is attempting to
>>organize this. I only discovered it a few weeks ago but had already
>>developed a few of my own tools to work with Struts and some that were
>>generic that I decided to stay focused on them to get my project going.
> Yeah, I didn't know if Veltools would be the right place or not. Will
> Veltools work with Turbine or is it meant to be standalone?

The Velocity Tools Project contains three subprojects. The VelocityLibrary
subproject is attempting exactly what you describe above. Have a look at the
documenation currently online at

The VelocityLibrary project is in a very early stage. It could really
use some input/feedback on how to best organize such a collection of tools
and what the interface between a toolbox manager and tools should look

> Is there a contrib area in Velocity or a sandbox to play in? (I don't see
> one in the tools subproject, does this stuff belong there?)

I think it would be nice to add them to the VelocityLibrary.

>>Here's what I have so far:
>>PageContextTool: This extends the PageContext interface in the
>>Servlet/JSP spec. I have not implemented a few of the methods since it
>>was mainly for use in adapting code that required a PageContext to get
>>the request, response, session, application and to find the scoped
>>attributes, etc.
>>MessageTool: This adapts the RequestUtils.message() in Struts to get
>>localized messages from a resource bundle (per Struts). I think it could
>>be made more generic, but it suited my needs so far.

The VelocityStruts projects contains a MessageTool. See

>>UtilityTool: General catch-all for conversion utilities, escaping HTML
>>characters, min/max, etc. It also hooks into the Common's project
>>corg.apache.commons.beanutils.BeanUtils.getProperty() for dynamic
>>property lookup (since $bean.$property is a syntax error in Velocity).
>>FormatTool: Date, time, number (currency, etc.) formatting sensitive to
>>locale and timezone.

Some of these certainly would be nice additions to the VelocityLibrary

>>VelocityTool: Experimental. I started this a few weeks ago and haven't
>>gotten pack to it. It provides for an evaluate method to perform dynamic
>>evaluations within a template. I had to suspend this the getProperty()
>>in the Utility tool solved my immediate need.
>>In terms of packaging, I think that in the realm of the ToolboxManager
>>in the velocity-tools area. 

VelocityViewServlet in the Velocity Tools projects currently supports a
XML file to define tools. The format is this:

<?xml version="1.0"?>


>>Another approach might be to have a Toolbox
>>tool in the context  that you can use at the top of your template to
>>"declare" the tool:
>>#set ( $fmt = $toolbox.get( "/WEB-INF/vmlibs/FormatTool" ) )

That's the ToolLoader tool in VelocityLibrary:
(doc it not 100% uptodate). See also the online demo at:

>>Anyway...that my run on this for the moment. Maybe the available tools
>>in need more visibility to get a chain reaction going and contributions.

I think that's the case. In  addition, we need input on how to best organize
and manage such a collection of tools. Should the collection of tools be
tightly managed by the Velocity comitters or should it be more a loosely
managed approach were everybody can contribute to a contrib area?


> Good, now we have some discussion going on!
> -warner
> --
> To unsubscribe, e-mail:   <>
> For additional commands, e-mail: <>

Gabriel Sidler
Software Engineer, Eivycom GmbH, Zurich, Switzerland

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message