You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@velocity.apache.org by Warner Onstine <sw...@warneronstine.com> on 2002/05/16 02:19:18 UTC
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Velocity vmlibs
Posted by Nathan Bubna <na...@esha.com>.
Bill said:
[snip]
> 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).
cool. share if you can!
> FormatTool: Date, time, number (currency, etc.) formatting sensitive to
> locale and timezone.
yeah, we've got a DateTool in the tools library right now. i'm not thrilled
with it's current state, but i'm working on it. my next patch/proposal
should make locale & timezone support easier. number/currency formatting
is something we don't have right now. so again, if you can contribute it,
that'd be 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.
neat. there always seems to be someone looking for this sorta thing on the
user list every now and then. chances are that someone wants this.
> In terms of packaging, I think that in the realm of the ToolboxManager
> in the velocity-tools area.
the ToolboxManager stuff just went through a major redesign. now there is a
generic ToolboxManager interface and a few implementations thereof. it'd
be great if you'd check it out. the veltools community is pretty small so
far, so more feedback is good. i'd particularly check out the
XMLToolboxManager. it supports adding tools to the context, initializing
them, and also now supports string, number, and boolean data. here's a
quick example of a config file for it:
<toolbox>
<tool>
<key>foo</key>
<class>com.acme.FooTool</class>
</tool>
<data type="number">
<key>myweight</key>
<value>161.2</value>
</data>
</toolbox>
if you are working in a servlet environment, the ServletToolboxManager
offers the same function and adds support for placing tools in different
scopes. it's already integrated into the VelocityViewServlet, but i'm
curious to hear if people find it difficult to use with their own servlets.
[snip]
Nathan Bubna
nathan@esha.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Velocity vmlibs
Posted by Gabriel Sidler <si...@teamup.ch>.
Warner Onstine wrote:
> ----- Original Message -----
> From: "Bill Boland" <bo...@attbi.com>
> To: "'Velocity Developers List'" <ve...@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?
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
http://www.teamup.com/jakarta-velocity-tools/docs/index.html
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
like.
>
> 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
http://www.teamup.com/jakarta-velocity-tools/struts/docs/MessageTool.html
>>
>>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"?>
<toolbox>
<tool>
<key>toolLoader</key>
<class>org.apache.velocity.tools.tools.ToolLoader</class>
</tool>
<tool>
<key>msg</key>
<class>org.apache.velocity.tools.struts.MessageTool</class>
</tool>
...
</toolbox>
>>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:
http://www.teamup.com/jakarta-velocity-tools/tools/docs/ToolLoader.html
(doc it not 100% uptodate). See also the online demo at:
http://www.teamup.com:8080/velstrutsdemo/examples/context_tools/mathtool-demo.vm
>>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?
Gabe
>>
>>Bill
>>
>
> Good, now we have some discussion going on!
>
> -warner
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
--
Gabriel Sidler
Software Engineer, Eivycom GmbH, Zurich, Switzerland
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Velocity vmlibs
Posted by Warner Onstine <sw...@warneronstine.com>.
----- Original Message -----
From: "Bill Boland" <bo...@attbi.com>
To: "'Velocity Developers List'" <ve...@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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Velocity vmlibs
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 5/15/02 10:25 PM, "Bill Boland" <bo...@attbi.com> wrote:
[SNIP]
>
> 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.
Be sure the code is free of claim from others (like an employer), attach the
Apache Software License, format the code so we can stand it ;) and send to
the list.
[SNIP]
> 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.
I use this in another scripting environment I put together. (Well, "$tool =
new(<whatever>);", and control what <whatever> can be outside of the
script). It's really useful and still allows the environment to keep
control of what is going on.
> 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.
Excactly - having a set that are deemed 'harmless' available at all times
makes life easy for everyone.
>
> Of course, if you don't want anyone to do this, you can keep the ToolBox
> tool out of the context.
Right - or have a configuration that limits what can be asked for. Make it
throw and exception when someone asks for something verboten, and then noone
gets hurt - as the page won't render..
geir
--
Geir Magnusson Jr.
Research & Development, Adeptra Inc.
geirm@adeptra.com
+1-203-247-1713
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Velocity vmlibs
Posted by Bill Boland <bo...@attbi.com>.
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:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Velocity vmlibs
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 5/16/02 10:10 PM, "Terry Steichen" <te...@net-frame.com> wrote:
> Jon,
>
> I don't know enough about JSP to know exactly how to do what you're
> suggesting - but it sounds pretty interesting. Would you mind humoring me
> with couple more exmaples to help illustrate this (potentially fascinating)
> approach?
>
I think he's just saying take the core of the taglib, which has the
functionality, and use it as a tool... Just drop it into the context....
> Regards,
>
> Terry
>
> ----- Original Message -----
> From: "Jon Scott Stevens" <jo...@latchkey.com>
> To: "velocity-dev" <ve...@jakarta.apache.org>
> Sent: Thursday, May 16, 2002 12:09 PM
> Subject: Re: Velocity vmlibs
>
>
>> on 5/15/02 5:19 PM, "Warner Onstine" <sw...@warneronstine.com> wrote:
>>
>>> 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 =)?
>>
>> Why not just take the beans which drive the taglibs and stick them in the
>> Context? ;-)
>>
>> $calendar.renderDate("2002-05-24")
>>
>> (or whatever it is)
>>
>> -jon
>>
>>
>> --
>> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
>> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>>
>>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
Geir Magnusson Jr.
Research & Development, Adeptra Inc.
geirm@adeptra.com
+1-203-247-1713
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Velocity vmlibs
Posted by Gabriel Sidler <si...@teamup.ch>.
Warner Onstine wrote:
...
>
> Maybe some kind of LuceneTool, CalendarTool, WorkflowTool (based off of the
> stuff in commons).
Could you briefly sketch what these tools would do?
>
> Give me some time I can probably come up with more.
Gabe
--
Gabriel Sidler
Software Engineer, Eivycom GmbH, Zurich, Switzerland
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Veltools] query result tool Was: Re: Velocity vmlibs
Posted by Gabriel Sidler <si...@teamup.ch>.
Nathan Bubna wrote:
> Nathan said:
>
>>>>Tools I'd like to see added:
>>>>
>>>>- CurrencyTool: Tool to format currencies
>>>>- TablePagerTool: Tool to render a large DB query result page by page.
>>>>
>>>I would specifically love to see something like this (especially if it
>>>
>>works
>>
>>>with Collections).
>>>
>>i have something like this that I use quite a bit. i posted a version
>>
> some
>
>>ages back called SearchTool. I'll see if i can't find some time to clean
>>it up and repost it.
>>
>
> Ok, i've cleaned up the aforementioned tool a bit, so here it is.
>
> Basically, it's an abstract tool that deals with most of the work needed to
> page thru a large List of query results efficiently. Implementations of it
> need only implement three methods (executeQuery(), getStoredResults(), and
> setStoredResults()) and set the search criteria and page index. This allows
> you to control where the current result list is stored and, of course,
> perform whatever query you wish.
>
> i've also attached the demo implementation and template that i used to test
> it. (Gabe, perhaps this could be worked into an example app somehow?)
>
> hope this works for ya'll.
Great! I'll add this soon and also setup some examples. That's something
I had planned anyway.
Gabe
--
Gabriel Sidler
Software Engineer, Eivycom GmbH, Zurich, Switzerland
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
[Veltools] query result tool Was: Re: Velocity vmlibs
Posted by Nathan Bubna <na...@esha.com>.
Nathan said:
> > > Tools I'd like to see added:
> > >
> > > - CurrencyTool: Tool to format currencies
> > > - TablePagerTool: Tool to render a large DB query result page by page.
> >
> > I would specifically love to see something like this (especially if it
> works
> > with Collections).
>
> i have something like this that I use quite a bit. i posted a version
some
> ages back called SearchTool. I'll see if i can't find some time to clean
> it up and repost it.
Ok, i've cleaned up the aforementioned tool a bit, so here it is.
Basically, it's an abstract tool that deals with most of the work needed to
page thru a large List of query results efficiently. Implementations of it
need only implement three methods (executeQuery(), getStoredResults(), and
setStoredResults()) and set the search criteria and page index. This allows
you to control where the current result list is stored and, of course,
perform whatever query you wish.
i've also attached the demo implementation and template that i used to test
it. (Gabe, perhaps this could be worked into an example app somehow?)
hope this works for ya'll.
Nathan Bubna
nathan@esha.com
Re: Velocity vmlibs
Posted by Claude Brisson <cl...@savoirweb.com>.
> the DateTool in their does already have some measure of Calendar support,
> but like I said, it still needs some work. i envision it being something
> more than just a date formatter, but it's not really there yet.
what about the proposal I posted here 3 days ago ?
it's just a beginning, but being able to parse a date in a specific format is quite usefull.
I recall what it is : a toDate(format,object) method.
CloD
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Velocity vmlibs
Posted by Nathan Bubna <na...@esha.com>.
Warner said:
[snip]
> > In addition, Velocity Tools includes the VelocityViewServlet with has
> > support to autoload tools into the context in a servlet environment.
>
> One of the questions I had earlier still remains unanswered (probably got
> missed in the whole exchange).
>
> Does the Toolbox stuff work with Turbine at all? I have a few components I
> will be building that I would like to share easily, but they need to run
in
> Turbine. Is this possible?
I think it probably is possible, but I haven't looked into it at all. If
you give it a shot, then I'd love to hear how it worked out!
> > Tools I'd like to see added:
> >
> > - CurrencyTool: Tool to format currencies
> > - TablePagerTool: Tool to render a large DB query result page by page.
>
> I would specifically love to see something like this (especially if it
works
> with Collections).
i have something like this that I use quite a bit. i posted a version some
ages back called SearchTool. I'll see if i can't find some time to clean
it up and repost it.
> > - TemplateTool: A tool to build composite views, similar to the Tiles
> > taglib in the Struts environment
> > - various form tools: Support for building HTML forms, auto-generation
of
> > lists, auto-population of lists and radio button groups, form
input
> > validation (client-side, server-side), etc.
> > - tools to support internationalized content
> >
> > What else?
>
> Maybe some kind of LuceneTool, CalendarTool, WorkflowTool (based off of
the
> stuff in commons).
the DateTool in their does already have some measure of Calendar support,
but like I said, it still needs some work. i envision it being something
more than just a date formatter, but it's not really there yet.
[snip]
Nathan Bubna
nathan@esha.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Velocity vmlibs
Posted by Warner Onstine <sw...@warneronstine.com>.
----- Original Message -----
From: "Gabriel Sidler" <si...@teamup.ch>
To: "Velocity Developers List" <ve...@jakarta.apache.org>
Sent: Friday, May 17, 2002 2:09 AM
Subject: Re: Velocity vmlibs
> Bill Boland wrote:
>
> ...
>
> > A VSTL (Velocity Standard Tool Library) would be a nice offering
> > (beginning with the tools in the velocity-tools already). I think we
> > should propose what tools we need developed or what we can offer to a
> > library and develop a plan. Maybe there is one and I'm just too green on
> > the scene! But, in this area is where I'm planning to contribute over
> > the next few weeks, if I may.
> >
> > bill
>
>
> That sounds good. Here's a list of what we currently have in Velocity
Tools:
>
> General Purpose Tools:
> - DateTool: Format dates, with locale support
> - MathTool: Math functions, the more important functions from
java.lang.Math
> - ParameterParser: Tool for easy parsing of ServletRequest parameters
> - ToolLoader: Allows loading of tools from withing templates
> - MultiViewsTool: Allows for content negotiation in a manner similar to
Apache
> http's MultiViews
>
> Tools for Velocity/Struts Integration:
> - MessageTool: Renders internationalized message strings.
> - LinkTool: Work with URIs
> - ErrorsTool: Handling of Struts error messages
> - FormTool: Support for working with HTML forms
>
> In addition, Velocity Tools includes the VelocityViewServlet with has
> support to autoload tools into the context in a servlet environment.
One of the questions I had earlier still remains unanswered (probably got
missed in the whole exchange).
Does the Toolbox stuff work with Turbine at all? I have a few components I
will be building that I would like to share easily, but they need to run in
Turbine. Is this possible?
> Tools I'd like to see added:
>
> - CurrencyTool: Tool to format currencies
> - TablePagerTool: Tool to render a large DB query result page by page.
I would specifically love to see something like this (especially if it works
with Collections).
> - TemplateTool: A tool to build composite views, similar to the Tiles
> taglib in the Struts environment
> - various form tools: Support for building HTML forms, auto-generation of
> lists, auto-population of lists and radio button groups, form input
> validation (client-side, server-side), etc.
> - tools to support internationalized content
>
> What else?
Maybe some kind of LuceneTool, CalendarTool, WorkflowTool (based off of the
stuff in commons).
Give me some time I can probably come up with more.
> Gabe
>
>
>
>
> --
> Gabriel Sidler
> Software Engineer, Eivycom GmbH, Zurich, Switzerland
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Velocity vmlibs
Posted by Gabriel Sidler <si...@teamup.ch>.
Bill Boland wrote:
...
> A VSTL (Velocity Standard Tool Library) would be a nice offering
> (beginning with the tools in the velocity-tools already). I think we
> should propose what tools we need developed or what we can offer to a
> library and develop a plan. Maybe there is one and I'm just too green on
> the scene! But, in this area is where I'm planning to contribute over
> the next few weeks, if I may.
>
> bill
That sounds good. Here's a list of what we currently have in Velocity Tools:
General Purpose Tools:
- DateTool: Format dates, with locale support
- MathTool: Math functions, the more important functions from java.lang.Math
- ParameterParser: Tool for easy parsing of ServletRequest parameters
- ToolLoader: Allows loading of tools from withing templates
- MultiViewsTool: Allows for content negotiation in a manner similar to Apache
http's MultiViews
Tools for Velocity/Struts Integration:
- MessageTool: Renders internationalized message strings.
- LinkTool: Work with URIs
- ErrorsTool: Handling of Struts error messages
- FormTool: Support for working with HTML forms
In addition, Velocity Tools includes the VelocityViewServlet with has
support to autoload tools into the context in a servlet environment.
Tools I'd like to see added:
- CurrencyTool: Tool to format currencies
- TablePagerTool: Tool to render a large DB query result page by page.
- TemplateTool: A tool to build composite views, similar to the Tiles
taglib in the Struts environment
- various form tools: Support for building HTML forms, auto-generation of
lists, auto-population of lists and radio button groups, form input
validation (client-side, server-side), etc.
- tools to support internationalized content
What else?
Gabe
--
Gabriel Sidler
Software Engineer, Eivycom GmbH, Zurich, Switzerland
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Velocity vmlibs
Posted by Nathan Bubna <na...@esha.com>.
Warner said:
[snip]
> Ahh, see that was also a part of my e-mail that I meant to put in, but
> didn't explicitly state - the macro side of things. How would deploying
> custom macros work?
just specify the library in your velocity properties
see the section on Velocimacros in:
http://jakarta.apache.org/velocity/developer-guide.html#Velocity%20Configura
tion%20Keys%20and%20Values
Nathan Bubna
nathan@esha.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Velocity vmlibs
Posted by Warner Onstine <sw...@warneronstine.com>.
----- Original Message -----
From: "Nathan Bubna" <na...@esha.com>
To: "Velocity Developers List" <ve...@jakarta.apache.org>
Sent: Friday, May 17, 2002 10:33 AM
Subject: Re: Velocity vmlibs
> Tim said:
> [snip]
> > There is one concern I have after reading the examples. One of the
> > problems I have with taglibs are those that incorporate HTML. ex.
> > "DropDownListCreatorTool" or "TableTool".
> >
> > I may be beating a dead horse here, but I would just hate to see us
> > commit the same offense by creating a servlet "tool" using Java that has
> > out += "<TD>" + foo + "</TD>" inside of it!
> >
> > A huge advantage that Velocity has, IMHO, are the Macros for creating
> > re-usable VIEW components.
> >
> > So howabout we create both VSTL and VSML (Velocity Standard Macro
> > Library)?
>
> +1 afaik, this has pretty much been the plan for a while, and i'm pretty
> sure they're all markup-free so far. we had a close shave with the struts
> ErrorTool, but we made it thru free of markup so far. :-)
Ahh, see that was also a part of my e-mail that I meant to put in, but
didn't explicitly state - the macro side of things. How would deploying
custom macros work?
-warner
> Nathan Bubna
> nathan@esha.com
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Velocity vmlibs
Posted by Nathan Bubna <na...@esha.com>.
Tim said:
[snip]
> There is one concern I have after reading the examples. One of the
> problems I have with taglibs are those that incorporate HTML. ex.
> "DropDownListCreatorTool" or "TableTool".
>
> I may be beating a dead horse here, but I would just hate to see us
> commit the same offense by creating a servlet "tool" using Java that has
> out += "<TD>" + foo + "</TD>" inside of it!
>
> A huge advantage that Velocity has, IMHO, are the Macros for creating
> re-usable VIEW components.
>
> So howabout we create both VSTL and VSML (Velocity Standard Macro
> Library)?
+1 afaik, this has pretty much been the plan for a while, and i'm pretty
sure they're all markup-free so far. we had a close shave with the struts
ErrorTool, but we made it thru free of markup so far. :-)
Nathan Bubna
nathan@esha.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Velocity vmlibs
Posted by Bill Boland <bo...@attbi.com>.
+1 for both the VSML as well as the VSTL. I think they work hand and
hand and the VSML will take advantage of the VSTL. I hope to examine the
existing tools some this weekend and start some contributions
myself...and get to know the toolbox manager.
-----Original Message-----
From: Tim Colson [mailto:tcolson@cisco.com]
Sent: Friday, May 17, 2002 9:25 AM
To: 'Velocity Developers List'
Subject: RE: Velocity vmlibs
Bill -
Thanks so much for the detailed explanation... as you noted, I've been
down that same path quite a bit and been left in the woods (having never
mucked around with the internals of a taglib).
> A VSTL (Velocity Standard Tool Library) would be a nice
> offering (beginning with the tools in the velocity-tools
> already). I think we should propose what tools we need
> developed or what we can offer to a library and develop a
> plan.
Great idea...and as noted by Gabe, something akin to that has been
started.
There is one concern I have after reading the examples. One of the
problems I have with taglibs are those that incorporate HTML. ex.
"DropDownListCreatorTool" or "TableTool".
I may be beating a dead horse here, but I would just hate to see us
commit the same offense by creating a servlet "tool" using Java that has
out += "<TD>" + foo + "</TD>" inside of it!
A huge advantage that Velocity has, IMHO, are the Macros for creating
re-usable VIEW components.
So howabout we create both VSTL and VSML (Velocity Standard Macro
Library)?
A file (ex. global_vsml.vm) could then be included with the distro that
contains the "standard" macros that a Designer could [mostly] rely on
having these across all Velocity enabled sites out of the box.
The example (or a more robust form) from the user-docs could be the
first one to be included ;-)
#macro( tablerows $color $somelist )
#foreach( $something in $somelist )
<tr><td bgcolor=$color>$something</td></tr>
#end
#end
This would also give, I hope, Designers some ideas to build upon for
their own Macros. This is such a powerful feature, but I think it
probably takes a bit of work to get JoeBob Designer to understand that
he now has the power to create
#ReallyFunkyDHTMLBoxForHelpText($helptext) or #MenuBar($listofmenuitems)
- WITHOUT a Developer! :-)
Cheers,
Tim
P.S. Joel Spolksy has some great articles on SW dev... the more I read,
the more I'm convinced they are Good Things To Do. Wondering to myself
if somebody writing a Spec for the tools so others can
design/build/qa/publish them according to that spec would be a positive
thing? http://www.joelonsoftware.com/articles/fog0000000036.html
--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Velocity vmlibs
Posted by Tim Colson <tc...@cisco.com>.
Bill -
Thanks so much for the detailed explanation... as you noted, I've been
down that same path quite a bit and been left in the woods (having never
mucked around with the internals of a taglib).
> A VSTL (Velocity Standard Tool Library) would be a nice
> offering (beginning with the tools in the velocity-tools
> already). I think we should propose what tools we need
> developed or what we can offer to a library and develop a
> plan.
Great idea...and as noted by Gabe, something akin to that has been
started.
There is one concern I have after reading the examples. One of the
problems I have with taglibs are those that incorporate HTML. ex.
"DropDownListCreatorTool" or "TableTool".
I may be beating a dead horse here, but I would just hate to see us
commit the same offense by creating a servlet "tool" using Java that has
out += "<TD>" + foo + "</TD>" inside of it!
A huge advantage that Velocity has, IMHO, are the Macros for creating
re-usable VIEW components.
So howabout we create both VSTL and VSML (Velocity Standard Macro
Library)?
A file (ex. global_vsml.vm) could then be included with the distro that
contains the "standard" macros that a Designer could [mostly] rely on
having these across all Velocity enabled sites out of the box.
The example (or a more robust form) from the user-docs could be the
first one to be included ;-)
#macro( tablerows $color $somelist )
#foreach( $something in $somelist )
<tr><td bgcolor=$color>$something</td></tr>
#end
#end
This would also give, I hope, Designers some ideas to build upon for
their own Macros. This is such a powerful feature, but I think it
probably takes a bit of work to get JoeBob Designer to understand that
he now has the power to create
#ReallyFunkyDHTMLBoxForHelpText($helptext) or #MenuBar($listofmenuitems)
- WITHOUT a Developer! :-)
Cheers,
Tim
P.S. Joel Spolksy has some great articles on SW dev... the more I read,
the more I'm convinced they are Good Things To Do. Wondering to myself
if somebody writing a Spec for the tools so others can
design/build/qa/publish them according to that spec would be a positive
thing? http://www.joelonsoftware.com/articles/fog0000000036.html
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Velocity vmlibs
Posted by Terry Steichen <te...@net-frame.com>.
Bill Boland explained the issue - Jon Stevens simply dismissed it with the
comment: "I'm not quite sure what else you are asking for. This is pretty
simple stuff." In other words, why are you asking such stupid questions and
wasting our precious time.
It's fine (perhaps for his ego?) to cover by saying (after the fact) "I
never said that people don't put stupid dependencies in their beans". But
it doesn't help people (like me) who really didn't understand the concept
(as I thought I candidly explained/admitted).
Bill Boland's reply was *much* more helpful - and I (apparently along with
others) appreciate it.
Regards,
Terry Steichen
----- Original Message -----
From: "Jon Scott Stevens" <jo...@latchkey.com>
To: "velocity-dev" <ve...@jakarta.apache.org>
Sent: Friday, May 17, 2002 7:29 PM
Subject: Re: Velocity vmlibs
> on 5/16/02 11:56 PM, "Bill Boland" <bo...@attbi.com> wrote:
>
> > And as for this SizeTag bean, it isn't as simple as just dropping it
> > into the context. Minimally, you might have to do the following on a
> >
> > SizeBean to place it into context so it can be "used".
> > SizeTag sizeTagBean = new SizeTag();
> > sizeTagBean.setPageContext( pageContext );
> > context.put( "size", sizeTagBean );
>
> I never said that people didn't put stupid dependencies in their beans.
;-)
>
> > and this assumes you have a PageContext object. To use it in a template
> > it might like:
> >
> > #set ( $dummy = $size.setId( "itemListSize" ) )
> > #set ( $dummy = $size.setName( "itemList" ) )
> > #set ( $dummy = $size.doStartTag() )
> > #set ( $itemListSize = $pageContext.getAttribute( "itemListSize"
> > ) )
> > ...
>
> Right...so clearly the functionality could be broken out to get at the
> 'meat' of the tool without the extra crap...
>
> > (There's isn't a public method on the tag bean to actually get the size.
> > The doStartTag() method begins the behavior of the tag bean after the
> > parameters have been set and placing results into page context
> > attributes or writing out to the response stream.)
> >
> > Once it's used, it probably should not be reused since many tag beans
> > hold state and cannot be used as reusable tools on a page. That's why
> > most are created new each time they are used on a page so the default
> > settings for that tag are restored.
>
> My god. Why the HELL does anyone use that crap?
>
> > But I have seen some that have been well designed and their
> > underlying bean libraries could be used. Usually, the beans already
> > existed and somebody wrote a tag adapter to them.
>
> Right...that is what I was assuming would have been done and the basis for
> my original statements...
>
> It is all just java objects after all...
>
> > Warner's original intent of this thread was to develop tool libraries
> > for use with Velocity that give newbies more desire to use it with these
> > neat prepackaged tools. Then standardize the tools to some degree so
> > that they can then foster collections of macro libraries that use these
> > standard tools and pages and applications that are build on Velocity. If
> > JSP taglibs tag beans can be adapted or their underlying code
> > reused...so much the better. If not, we blaze a new trail out of the
> > dark woods.
>
> That is why I started the Turbine project...the whole idea behind it was
to
> try to standardize webapp development. Back in the day of early servlet
> development, there was 50 different classes just to parse query
data...now,
> people don't even think about that stuff...
>
> -jon
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Velocity vmlibs
Posted by Jon Scott Stevens <jo...@latchkey.com>.
on 5/16/02 11:56 PM, "Bill Boland" <bo...@attbi.com> wrote:
> And as for this SizeTag bean, it isn't as simple as just dropping it
> into the context. Minimally, you might have to do the following on a
>
> SizeBean to place it into context so it can be "used".
> SizeTag sizeTagBean = new SizeTag();
> sizeTagBean.setPageContext( pageContext );
> context.put( "size", sizeTagBean );
I never said that people didn't put stupid dependencies in their beans. ;-)
> and this assumes you have a PageContext object. To use it in a template
> it might like:
>
> #set ( $dummy = $size.setId( "itemListSize" ) )
> #set ( $dummy = $size.setName( "itemList" ) )
> #set ( $dummy = $size.doStartTag() )
> #set ( $itemListSize = $pageContext.getAttribute( "itemListSize"
> ) )
> ...
Right...so clearly the functionality could be broken out to get at the
'meat' of the tool without the extra crap...
> (There's isn't a public method on the tag bean to actually get the size.
> The doStartTag() method begins the behavior of the tag bean after the
> parameters have been set and placing results into page context
> attributes or writing out to the response stream.)
>
> Once it's used, it probably should not be reused since many tag beans
> hold state and cannot be used as reusable tools on a page. That's why
> most are created new each time they are used on a page so the default
> settings for that tag are restored.
My god. Why the HELL does anyone use that crap?
> But I have seen some that have been well designed and their
> underlying bean libraries could be used. Usually, the beans already
> existed and somebody wrote a tag adapter to them.
Right...that is what I was assuming would have been done and the basis for
my original statements...
It is all just java objects after all...
> Warner's original intent of this thread was to develop tool libraries
> for use with Velocity that give newbies more desire to use it with these
> neat prepackaged tools. Then standardize the tools to some degree so
> that they can then foster collections of macro libraries that use these
> standard tools and pages and applications that are build on Velocity. If
> JSP taglibs tag beans can be adapted or their underlying code
> reused...so much the better. If not, we blaze a new trail out of the
> dark woods.
That is why I started the Turbine project...the whole idea behind it was to
try to standardize webapp development. Back in the day of early servlet
development, there was 50 different classes just to parse query data...now,
people don't even think about that stuff...
-jon
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Velocity vmlibs
Posted by Bill Boland <bo...@attbi.com>.
Tags are beans...but they do have several dependencies on other objects
in the JSP world (PageContext, JspWriter, etc.) and are poked and
prodded a bit by their JSP containers before the methods are called from
within the JSP pages.
An example to illustrate this. The Struts <bean:size/> tag returns the
size of a Collection or Map (for more info, see
http://jakarta.apache.org/struts/userGuide/struts-bean.html#size).
Within the JSP page it looks something like:
<bean:size id="itemListSize" name="itemList" />
When it is compiled by Tomcat 4 into java code, it turns into the
following snippet of code:
/* ---- bean:size ---- */
org.apache.struts.taglib.bean.SizeTag
_jspx_th_bean_size_0 = new org.apache.struts.taglib.bean.SizeTag();
_jspx_th_bean_size_0.setPageContext(pageContext);
_jspx_th_bean_size_0.setParent(null);
_jspx_th_bean_size_0.setId("itemListSize");
_jspx_th_bean_size_0.setName("itemList");
java.lang.Integer itemListSize = null;
try {
int _jspx_eval_bean_size_0 =
_jspx_th_bean_size_0.doStartTag();
itemListSize = (java.lang.Integer)
pageContext.findAttribute("itemListSize");
if (_jspx_eval_bean_size_0 ==
javax.servlet.jsp.tagext.BodyTag.EVAL_BODY_BUFFERED)
throw new JspTagException("Since tag handler
class org.apache.struts.taglib.bean.SizeTag does not implement BodyTag,
it can't return BodyTag.EVAL_BODY_TAG");
if (_jspx_eval_bean_size_0 !=
javax.servlet.jsp.tagext.Tag.SKIP_BODY) {
do {
itemListSize = (java.lang.Integer)
pageContext.findAttribute("itemListSize");
// end
// begin
[file="listUsers.jsp";from=(8,0);to=(8,47)]
} while (_jspx_th_bean_size_0.doAfterBody() ==
javax.servlet.jsp.tagext.BodyTag.EVAL_BODY_AGAIN);
itemListSize = (java.lang.Integer)
pageContext.findAttribute("itemListSize");
}
if (_jspx_th_bean_size_0.doEndTag() ==
javax.servlet.jsp.tagext.Tag.SKIP_PAGE)
return;
} finally {
_jspx_th_bean_size_0.release();
}
If this isn't enough to convince one to move to Velocity or use a better
strategy, I'm not sure what is.
I find
#set ( $itemListSize = $req.getAttribute( "itemList" ).size() )
OR
#set ( $itemList = $req.getAttribute( "itemList" ) )
(using $itemList.size() when I need the size.)
much more desirable when working with Servlets than the tags. But, of
course, I'm preaching to the choir here.
And as for this SizeTag bean, it isn't as simple as just dropping it
into the context. Minimally, you might have to do the following on a
SizeBean to place it into context so it can be "used".
SizeTag sizeTagBean = new SizeTag();
sizeTagBean.setPageContext( pageContext );
context.put( "size", sizeTagBean );
and this assumes you have a PageContext object. To use it in a template
it might like:
#set ( $dummy = $size.setId( "itemListSize" ) )
#set ( $dummy = $size.setName( "itemList" ) )
#set ( $dummy = $size.doStartTag() )
#set ( $itemListSize = $pageContext.getAttribute( "itemListSize"
) )
...
(There's isn't a public method on the tag bean to actually get the size.
The doStartTag() method begins the behavior of the tag bean after the
parameters have been set and placing results into page context
attributes or writing out to the response stream.)
Once it's used, it probably should not be reused since many tag beans
hold state and cannot be used as reusable tools on a page. That's why
most are created new each time they are used on a page so the default
settings for that tag are restored.
I don't mean to make fun of this bean, JSPs (well...) or how it might be
used. Its interface and purpose were not intended for the template
world. Many taglibs have not been designed as "tag adapters" that
separate the "taggy-ness" or JSP glue from the actual bean logic. And,
if they do, the underlying beans may not be as well documented as the
tags. But I have seen some that have been well designed and their
underlying bean libraries could be used. Usually, the beans already
existed and somebody wrote a tag adapter to them.
The intent here is to learn from all of this and not go down a path that
is well worn but goes into the dark woods. Velocity has some great
technological challenges as well...and user acceptance and education
being probably the toughest nut to crack.
Warner's original intent of this thread was to develop tool libraries
for use with Velocity that give newbies more desire to use it with these
neat prepackaged tools. Then standardize the tools to some degree so
that they can then foster collections of macro libraries that use these
standard tools and pages and applications that are build on Velocity. If
JSP taglibs tag beans can be adapted or their underlying code
reused...so much the better. If not, we blaze a new trail out of the
dark woods.
A VSTL (Velocity Standard Tool Library) would be a nice offering
(beginning with the tools in the velocity-tools already). I think we
should propose what tools we need developed or what we can offer to a
library and develop a plan. Maybe there is one and I'm just too green on
the scene! But, in this area is where I'm planning to contribute over
the next few weeks, if I may.
bill
-----Original Message-----
From: Jon Scott Stevens [mailto:jon@latchkey.com]
Sent: Thursday, May 16, 2002 8:39 PM
To: velocity-dev
Subject: Re: Velocity vmlibs
on 5/16/02 7:10 PM, "Terry Steichen" <te...@net-frame.com> wrote:
> Jon,
>
> I don't know enough about JSP to know exactly how to do what you're
> suggesting - but it sounds pretty interesting. Would you mind
humoring me
> with couple more exmaples to help illustrate this (potentially
fascinating)
> approach?
>
> Regards,
>
> Terry
With Velocity, you put java.lang.Object's into the Context.
Given that a taglib is simply a java.lang.Object, you simply instantiate
it
and put it into the context. You can then call on its methods from
within
the Velocity template.
I'm not quite sure what else you are asking for. This is pretty simple
stuff.
-jon
--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Velocity vmlibs
Posted by Jon Scott Stevens <jo...@latchkey.com>.
on 5/16/02 7:10 PM, "Terry Steichen" <te...@net-frame.com> wrote:
> Jon,
>
> I don't know enough about JSP to know exactly how to do what you're
> suggesting - but it sounds pretty interesting. Would you mind humoring me
> with couple more exmaples to help illustrate this (potentially fascinating)
> approach?
>
> Regards,
>
> Terry
With Velocity, you put java.lang.Object's into the Context.
Given that a taglib is simply a java.lang.Object, you simply instantiate it
and put it into the context. You can then call on its methods from within
the Velocity template.
I'm not quite sure what else you are asking for. This is pretty simple
stuff.
-jon
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Velocity vmlibs
Posted by Terry Steichen <te...@net-frame.com>.
Jon,
I don't know enough about JSP to know exactly how to do what you're
suggesting - but it sounds pretty interesting. Would you mind humoring me
with couple more exmaples to help illustrate this (potentially fascinating)
approach?
Regards,
Terry
----- Original Message -----
From: "Jon Scott Stevens" <jo...@latchkey.com>
To: "velocity-dev" <ve...@jakarta.apache.org>
Sent: Thursday, May 16, 2002 12:09 PM
Subject: Re: Velocity vmlibs
> on 5/15/02 5:19 PM, "Warner Onstine" <sw...@warneronstine.com> wrote:
>
> > 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 =)?
>
> Why not just take the beans which drive the taglibs and stick them in the
> Context? ;-)
>
> $calendar.renderDate("2002-05-24")
>
> (or whatever it is)
>
> -jon
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Velocity vmlibs
Posted by Warner Onstine <sw...@warneronstine.com>.
Hmm, hadn't thought of that.
Thanks Jon!
-warner
----- Original Message -----
From: "Jon Scott Stevens" <jo...@latchkey.com>
To: "velocity-dev" <ve...@jakarta.apache.org>
Sent: Thursday, May 16, 2002 9:09 AM
Subject: Re: Velocity vmlibs
> on 5/15/02 5:19 PM, "Warner Onstine" <sw...@warneronstine.com> wrote:
>
> > 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 =)?
>
> Why not just take the beans which drive the taglibs and stick them in the
> Context? ;-)
>
> $calendar.renderDate("2002-05-24")
>
> (or whatever it is)
>
> -jon
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Velocity vmlibs
Posted by Jon Scott Stevens <jo...@latchkey.com>.
on 5/15/02 5:19 PM, "Warner Onstine" <sw...@warneronstine.com> wrote:
> 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 =)?
Why not just take the beans which drive the taglibs and stick them in the
Context? ;-)
$calendar.renderDate("2002-05-24")
(or whatever it is)
-jon
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>