velocity-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Warner Onstine" <sw-l...@warneronstine.com>
Subject Re: Velocity vmlibs
Date Thu, 16 May 2002 04:17:12 GMT

----- Original Message -----
From: "Bill Boland" <bolandb@attbi.com>
To: "'Velocity Developers List'" <velocity-dev@jakarta.apache.org>
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
> 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.

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?

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

That's an idea, although I don't know how well it fits with my core idea,
which is cool Velocity tools that I can also use in Turbine (plug and play
;-).

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

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

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

Very cool

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

It would be nicer to have a config file (a-la tag-libs) where this info gets
read and then you can just use it through the context (at least I think so,
haven't used Velocity standalone though so I don't know).

> 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

Good, now we have some discussion going on!

-warner


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