velocity-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Boland" <bola...@attbi.com>
Subject RE: Velocity vmlibs
Date Thu, 16 May 2002 02:25:22 GMT
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.

The velocity-tools (at
http://jakarta.apache.org/velocity/toolsubproject.html) 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.

Also, I thought that one great way to possibly leverage of all of the
taglib code base would be to just build simple adapters to some of the
popular tag libraries. I'm still exploring this but it might be nice to
use these libraries since they've already been built and many are
focused on presentation goals of Velocity. I've created my own
PageContext tool that I place into the Velocity context and could easily
be set into Tags or TagAdapters that require a PageContext object. I
created it for use with some Struts RequestUtils methods that also
required the PageContext but it may work for Tags as well. But if that
doesn't work, no big loss. Let's build our own. 

I'd be happy to contribute some that I write that are generic and
reusable in many situations...I'm just not certain on the best way to
contribute. 

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.

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.

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

OR
	#set ( $fmt = $toolbox.get(
"org.apache.velocity.tools.FormatTool" ) )

I'm just thinking off the cuff here so I have no idea what would be
correct...but it would be a similar declaration. The toolbox would have
access to the PageContext and the tools would require that they follow
some interface or naming pattern for initialization.

Now...I know that some may argue that these should be placed into
context prior to the merge and not be done in the template. I would
agree...and yet disagree. If I have a library of presentation tools at
my disposal, it would be nice for me, as the page designer, to pick and
choose the ones available to me. That way, I don't need ones placed into
my context that I don't use.

Of course, if you don't want anyone to do this, you can keep the ToolBox
tool out of the context.

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.

Bill


-----Original Message-----
From: Warner Onstine [mailto:sw-list@warneronstine.com] 
Sent: Wednesday, May 15, 2002 5:19 PM
To: Velocity Developers List
Subject: Velocity vmlibs

Not sure what to call this so I'm calling it vmlibs (kindof like
taglibs),
you all will have to let me know if this is already been discussed or is
even interesting.

One of the niceties of taglibs is their packed-ness, I can find a taglib
for
a lot of things (calendars, date time stuff, take a look at the jakarta
taglib project), drop in the jar and the tld file and away I go.
I hate JSP's *grin*, else why would I be here =)?

But I started thinking about what it would take to package a similar
thing
for Velocity, how would something like that work?

-warner

+warner onstine+


--
To unsubscribe, e-mail:
<mailto:velocity-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail:
<mailto:velocity-dev-help@jakarta.apache.org>




--
To unsubscribe, e-mail:   <mailto:velocity-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:velocity-dev-help@jakarta.apache.org>


Mime
View raw message