You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@velocity.apache.org by Nathan Bubna <na...@esha.com> on 2002/03/11 19:54:45 UTC
[VELTOOLS] tool contributions
Hey Geir, Gabe, et al
Attached are the latest versions of my MathTool and DateTool classes, both
of which are much-improved over the versions i contributed to 'rupert' way
back. Both are better documented, more robust, and have greater
functionality.
Also attached is a ParameterParser class that's come in pretty handy for me
in the last few weeks. It's basically an evolution of part of that sketchy
abstract PullTool class i committed about a month ago. it's a cinch to
use, just feed it a ServletRequest and it'll give you a clean and easy way
to parse/access the parameters.
As usual, you can take or leave as you like, but imho these fit nicely into
the vel-tools sub-project.
Nathan Bubna
nathan@esha.com
Re: [VELTOOLS] tool contributions
Posted by Nathan Bubna <na...@esha.com>.
Gabriel Sidler said:
[...]
> > it is an idea i considered briefly, but decided against for several
reasons.
> > for one, MathTool is completely static, there is no point or benefit to
> > implementing ContextTool or any other tool interface.
>
>
> Exactly in the case of an all static tool it is important to give
> the tool manager a hint that it does not need to recreate instances
> for each request. So, the proposed isStatic() method would allow a
> smart tool manager to use one instance for the entire runtime.
> How else do you distinguish between all static tools and non-static tools?
why do you need to distinguish? in the current ToolboxManager algorithm, if
a tool doesn't implement ContextTool, then the same instance is *already*
automatically used for the entire runtime. i don't see how this is
beneficial. i know i've certainly not run into a situation that begs for
it. if you have, please enlighten me.
> > but the main problem
> > i have with implementing ContextTool is that i do not use these tools
solely
> > with the VelocityViewServlet.
>
> Actually, the ContextTool interface is not desiged to be used with
> VelocityViewServlet only. It should be useful in any circumstance
> where you work with Velocity and tools. For example, I am thinking
> about DVSL.
uh, not so fast. implementing the ContextTool interface is completely
useless for a pull tool used in Turbine. i suspect the same would be true
with other frameworks. there is no functionality built in to deal with
ViewContexts or 'init' factory methods. Turbine already has its own system
for managing tools.
> > in fact, they were originally written to be
> > used in a Turbine/Velocity web app and are still primarily used there.
so I
> > don't think there is any benefit to tying these tools to the view
servlet.
>
> As said, the interface shouldn't tie the tools to the VelocityViewServlet
> at all. If the current draft does, we should change it to achive this
goal.
i should be more specific. the interface ties implementing tools to the
ViewContext class and a specific pattern of tool management that may not be
desired, needed, or useful when working with the tool in a different
framework.
Nathan Bubna
nathan@esha.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VELTOOLS] tool contributions
Posted by Gabriel Sidler <si...@teamup.ch>.
Nathan Bubna wrote:
> Gabe said:
> ...
>
>>I'd like to suggest that these tools also implement the
>>ContextTool interface. See also my next mail regarding
>>changes to the ContextTool interface.
>>
>
> i was wondering if someone would suggest that... :)
>
> it is an idea i considered briefly, but decided against for several reasons.
> for one, MathTool is completely static, there is no point or benefit to
> implementing ContextTool or any other tool interface.
Exactly in the case of an all static tool it is important to give
the tool manager a hint that it does not need to recreate instances
for each request. So, the proposed isStatic() method would allow a
smart tool manager to use one instance for the entire runtime.
How else do you distinguish between all static tools and non-static tools?
> but the main problem
> i have with implementing ContextTool is that i do not use these tools solely
> with the VelocityViewServlet.
Actually, the ContextTool interface is not desiged to be used with
VelocityViewServlet only. It should be useful in any circumstance
where you work with Velocity and tools. For example, I am thinking
about DVSL.
> in fact, they were originally written to be
> used in a Turbine/Velocity web app and are still primarily used there. so I
> don't think there is any benefit to tying these tools to the view servlet.
As said, the interface shouldn't tie the tools to the VelocityViewServlet
at all. If the current draft does, we should change it to achive this goal.
> my opinion of the ContextTool interface is that it is that it should be used
> *only* when necessary. otherwise, tools should remain as generic as
> possible so they can be easily used in a variety of different settings.
I completely agree with this statement. That's how I see it used. To be
followed up after I see your feedback to the proposal I just sent.
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] tool contributions
Posted by Nathan Bubna <na...@esha.com>.
Gabe said:
...
> I'd like to suggest that these tools also implement the
> ContextTool interface. See also my next mail regarding
> changes to the ContextTool interface.
i was wondering if someone would suggest that... :)
it is an idea i considered briefly, but decided against for several reasons.
for one, MathTool is completely static, there is no point or benefit to
implementing ContextTool or any other tool interface. but the main problem
i have with implementing ContextTool is that i do not use these tools solely
with the VelocityViewServlet. in fact, they were originally written to be
used in a Turbine/Velocity web app and are still primarily used there. so I
don't think there is any benefit to tying these tools to the view servlet.
my opinion of the ContextTool interface is that it is that it should be used
*only* when necessary. otherwise, tools should remain as generic as
possible so they can be easily used in a variety of different settings.
anyhow, i look forward to checking out the changes you just committed.
thanks for doing all that!
Nathan Bubna
nathan@esha.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VELTOOLS] tool contributions
Posted by Terry Steichen <te...@net-frame.com>.
+1
----- Original Message -----
From: "Geir Magnusson Jr." <ge...@optonline.net>
To: "Velocity Developer's List" <ve...@jakarta.apache.org>
Sent: Tuesday, March 12, 2002 8:40 AM
Subject: Re: [VELTOOLS] tool contributions
> On 3/12/02 8:39 AM, "Gabriel Sidler" <si...@teamup.ch> wrote:
>
> > Nathan,
> > these make nice additions to the planned VelTools library.
> >
> > I'd like to suggest that these tools also implement the
> > ContextTool interface. See also my next mail regarding
> > changes to the ContextTool interface.
>
> I think we should minimize as much as possible any special interfaces that
> tools must implement...
>
> I'll wait for your email before commenting further, but wanted to let you
> know how I feel about this.
>
> Tools should be able to be simple - we should be able to reuse any
existing
> tools that we have or find...
>
> Geir
>
>
> --
> Geir Magnusson Jr. geirm@optonline.net
> System and Software Consulting
> "Now what do we do?"
>
>
> --
> 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: [VELTOOLS] tool contributions
Posted by Gabriel Sidler <si...@teamup.ch>.
Geir Magnusson Jr. wrote:
> On 3/12/02 8:39 AM, "Gabriel Sidler" <si...@teamup.ch> wrote:
>
>
>>Nathan,
>>these make nice additions to the planned VelTools library.
>>
>>I'd like to suggest that these tools also implement the
>>ContextTool interface. See also my next mail regarding
>>changes to the ContextTool interface.
>>
>
> I think we should minimize as much as possible any special interfaces that
> tools must implement...
>
> I'll wait for your email before commenting further, but wanted to let you
> know how I feel about this.
>
> Tools should be able to be simple - we should be able to reuse any existing
> tools that we have or find...
>
> Geir
Geir, I agree that any class with public methods
should be usable as a context tool. The ContextTool interface
is not a MUST but a COULD. If a context tool implements the
interface there are some benefits like access to logging and the
possbility to reuse static tools across multiple requests.
Please check out my proposal. For my frequently used tools I
certainly would implement the interface. For infrequently used
tools probably not.
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] tool contributions
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 3/12/02 8:39 AM, "Gabriel Sidler" <si...@teamup.ch> wrote:
> Nathan,
> these make nice additions to the planned VelTools library.
>
> I'd like to suggest that these tools also implement the
> ContextTool interface. See also my next mail regarding
> changes to the ContextTool interface.
I think we should minimize as much as possible any special interfaces that
tools must implement...
I'll wait for your email before commenting further, but wanted to let you
know how I feel about this.
Tools should be able to be simple - we should be able to reuse any existing
tools that we have or find...
Geir
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
"Now what do we do?"
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VELTOOLS] tool contributions
Posted by Gabriel Sidler <si...@teamup.ch>.
Nathan,
these make nice additions to the planned VelTools library.
I'd like to suggest that these tools also implement the
ContextTool interface. See also my next mail regarding
changes to the ContextTool interface.
Gabe
Nathan Bubna wrote:
> Hey Geir, Gabe, et al
>
> Attached are the latest versions of my MathTool and DateTool classes, both
> of which are much-improved over the versions i contributed to 'rupert' way
> back. Both are better documented, more robust, and have greater
> functionality.
>
> Also attached is a ParameterParser class that's come in pretty handy for me
> in the last few weeks. It's basically an evolution of part of that sketchy
> abstract PullTool class i committed about a month ago. it's a cinch to
> use, just feed it a ServletRequest and it'll give you a clean and easy way
> to parse/access the parameters.
>
> As usual, you can take or leave as you like, but imho these fit nicely into
> the vel-tools sub-project.
>
> Nathan Bubna
> nathan@esha.com
>
>
> ------------------------------------------------------------------------
>
> --
> 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: [VELTOOLS] tool contributions
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 3/11/02 2:13 PM, "Nathan Bubna" <na...@esha.com> wrote:
>
> [snip]
>>> As usual, you can take or leave as you like, but imho these fit nicely
> into
>>> the vel-tools sub-project.
>>>
>>
>> Assuming licensing, formatting and they work as advertised, consider them
>> in...
>
> cool. i'll happily fix things if problems are found.
>
Never thought otherwise :)
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
Age and treachery will always triumph over youth and talent
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VELTOOLS] tool contributions
Posted by Nathan Bubna <na...@esha.com>.
[snip]
> > As usual, you can take or leave as you like, but imho these fit nicely
into
> > the vel-tools sub-project.
> >
>
> Assuming licensing, formatting and they work as advertised, consider them
> in...
cool. i'll happily fix things if problems are found.
Nathan Bubna
nathan@esha.com
>
> --
> Geir Magnusson Jr. geirm@optonline.net
> System and Software Consulting
> Java : the speed of Smalltalk with the simple elegance of C++...
>
>
> --
> 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: [VELTOOLS] tool contributions
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 3/11/02 1:54 PM, "Nathan Bubna" <na...@esha.com> wrote:
> Hey Geir, Gabe, et al
>
> Attached are the latest versions of my MathTool and DateTool classes, both
> of which are much-improved over the versions i contributed to 'rupert' way
> back. Both are better documented, more robust, and have greater
> functionality.
>
> Also attached is a ParameterParser class that's come in pretty handy for me
> in the last few weeks. It's basically an evolution of part of that sketchy
> abstract PullTool class i committed about a month ago. it's a cinch to
> use, just feed it a ServletRequest and it'll give you a clean and easy way
> to parse/access the parameters.
>
> As usual, you can take or leave as you like, but imho these fit nicely into
> the vel-tools sub-project.
>
Assuming licensing, formatting and they work as advertised, consider them
in...
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
Java : the speed of Smalltalk with the simple elegance of C++...
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>