You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@velocity.apache.org by Christoph Reck <Ch...@dlr.de> on 2002/04/04 10:07:28 UTC
Re: cvs commit: jakarta-velocity-tools/tools/xdocs
DateTool.xmlMathTool.xml ParameterParser.xml ToolLoader.xml
"Geir Magnusson Jr." wrote:
>
> On 4/3/02 12:46 PM, "Jon Scott Stevens" <jo...@latchkey.com> wrote:
>
> > on 4/3/02 1:10 AM, "sidler@apache.org" <si...@apache.org> wrote:
> >
> >> tools/src/java/org/apache/velocity/tools/tools DateTool.java
> >> MathTool.java ParameterParser.java ToolLoader.java
> >> package.html
> >
> > Why is it that these fiels are in a tools/tools directory?
> >
>
> Tools is the subpackage that holds all for the -tools project.
yuk!?
.../tools/tools/*Tool.java
In the commons sandbox the *Utils and *Tools was discussed and
the java.util.* approach was taken where the radix is just postfixed
with a plural - like java.util.Arrays, java.util.Collections,
Something like DateUtils became Dates, XmlUtils -> XmlStrings,
MathUtils -> Numbers or just Math (which has no plural form).
How about such an approach?
--
:) Christoph Reck
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-velocity-tools/tools/xdocsDateTool.xmlMathTool.xml ParameterParser.xml ToolLoader.xml
Posted by Nathan Bubna <na...@esha.com>.
Geir said:
> But my impression is that this is getting a bit over-designed : I am going
> to read the whole thread tomorrow - but has everyone stood back and asked
> the question (or answered it) :
>
> Is there anything we can remove?
yup, plenty if you ask me.
> I like very much the idea of placing few if any requirements on the
tools -
> that the toolbox descriptor should suffice -> I would want to be able to
> specify java.lang.String as a tool and control where and how it was
used...
i agree. i think my proposal (already implemented and submitted) for
putting scope-placement wholly to the config file and having two completely
optional interfaces--one for application tools and one for request/session
tools--should suffice.
if that's still too much stuff for you, i personally don't ever plan on
using the application tool interface i proposed (ServletContextTool), i only
think it is something that someone may want. perhaps we should stick with
just the one interface i proposed for request/session tools
(ViewContextTool) and add the other later if someone actually wants it.
the issues of logging and pooling for tools are of secondary importance to
me.
> And I am afraid that outside of the Struts integration part, it's getting
> framework-ish...
heh. that may be... perhaps we should leave any special logging or pooling
for tools out. after all, tools that implement either of my proposed
interfaces have access to the servlet context and can just log directly thru
that if need be. other than that, logging can easily be left for developers
to implement on their own. also, i suppose we should think carefully before
implementing anything that will add new dependencies (such as pooling).
> However, these are just random thoughts at the end of a long day towards
the
> end of a long week at the beginning of what will be a long month - so I
may
> be totally off base....
no, i don't think you're off base at all. simple and clean sounds good to
me.
Nathan Bubna
nathan@esha.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-velocity-tools/tools/xdocs DateTool.xmlMathTool.xml ParameterParser.xml ToolLoader.xml
Posted by Daniel Rall <dl...@finemaltcoding.com>.
"Geir Magnusson Jr." <ge...@optonline.net> writes:
> I like very much the idea of placing few if any requirements on the tools -
> that the toolbox descriptor should suffice -> I would want to be able to
> specify java.lang.String as a tool and control where and how it was used...
Indeed, _any_ Java class or primitive should be able to be added to
the toolbox (just as in DVSL). This is a very useful and powerful
piece of functionality. Additionally, when adding objects to the
toolbox I would find it very useful for an alternate Factory to be use
which has the ability to do object pooling and perform
initialization/resource reclamation activites. This allows a certain
amount of framework functionality without introducing an actual
framework -- just an integration point.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-velocity-tools/tools/xdocs
DateTool.xmlMathTool.xml ParameterParser.xml ToolLoader.xml
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 4/4/02 9:29 PM, "Daniel Rall" <dl...@finemaltcoding.com> wrote:
> "Geir Magnusson Jr." <ge...@optonline.net> writes:
>
>> If the problem is tools/tools/...
>>
>> Why not
>>
>> tools/library/...
>>
>> As suggested by the docs...
>
> +1, that sounds _much_ nicer.
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
General comment - I was too busy today to jump into the tools fray (too busy
working for client)...
But my impression is that this is getting a bit over-designed : I am going
to read the whole thread tomorrow - but has everyone stood back and asked
the question (or answered it) :
Is there anything we can remove?
I like very much the idea of placing few if any requirements on the tools -
that the toolbox descriptor should suffice -> I would want to be able to
specify java.lang.String as a tool and control where and how it was used...
And I am afraid that outside of the Struts integration part, it's getting
framework-ish...
However, these are just random thoughts at the end of a long day towards the
end of a long week at the beginning of what will be a long month - so I may
be totally off base....
geir
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
The question is : What is a Mahnamahna?
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-velocity-tools/tools/xdocs DateTool.xmlMathTool.xml ParameterParser.xml ToolLoader.xml
Posted by Daniel Rall <dl...@finemaltcoding.com>.
"Geir Magnusson Jr." <ge...@optonline.net> writes:
> If the problem is tools/tools/...
>
> Why not
>
> tools/library/...
>
> As suggested by the docs...
+1, that sounds _much_ nicer.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-velocity-tools/tools/xdocs
DateTool.xmlMathTool.xml ParameterParser.xml ToolLoader.xml
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 4/4/02 1:27 PM, "Daniel Rall" <dl...@finemaltcoding.com> wrote:
> Christoph Reck <Ch...@dlr.de> writes:
>
>> "Geir Magnusson Jr." wrote:
>>>
>>> On 4/3/02 12:46 PM, "Jon Scott Stevens" <jo...@latchkey.com> wrote:
>>>
>>>> on 4/3/02 1:10 AM, "sidler@apache.org" <si...@apache.org> wrote:
>>>>
>>>>> tools/src/java/org/apache/velocity/tools/tools DateTool.java
>>>>> MathTool.java ParameterParser.java ToolLoader.java
>>>>> package.html
>>>>
>>>> Why is it that these fiels are in a tools/tools directory?
>>>>
>>>
>>> Tools is the subpackage that holds all for the -tools project.
>>
>> yuk!?
>> .../tools/tools/*Tool.java
>>
>> In the commons sandbox the *Utils and *Tools was discussed and
>> the java.util.* approach was taken where the radix is just postfixed
>> with a plural - like java.util.Arrays, java.util.Collections,
>> Something like DateUtils became Dates, XmlUtils -> XmlStrings,
>> MathUtils -> Numbers or just Math (which has no plural form).
>>
>> How about such an approach?
>
> That worked well for the Commons packages, but I'm not sure how well
> it applies to the class names of the Java source files in the tools
> component. If I've got it right now, these are context/pull tools.
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
If the problem is tools/tools/...
Why not
tools/library/...
As suggested by the docs...
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
"The greatest pleasure in life is doing what people say you cannot do."
- Walter Bagehot
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-velocity-tools/tools/xdocs DateTool.xmlMathTool.xml ParameterParser.xml ToolLoader.xml
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Christoph Reck <Ch...@dlr.de> writes:
> "Geir Magnusson Jr." wrote:
> >
>> On 4/3/02 12:46 PM, "Jon Scott Stevens" <jo...@latchkey.com> wrote:
>>
>> > on 4/3/02 1:10 AM, "sidler@apache.org" <si...@apache.org> wrote:
>> >
>> >> tools/src/java/org/apache/velocity/tools/tools DateTool.java
>> >> MathTool.java ParameterParser.java ToolLoader.java
>> >> package.html
>> >
>> > Why is it that these fiels are in a tools/tools directory?
>> >
>>
>> Tools is the subpackage that holds all for the -tools project.
>
> yuk!?
> .../tools/tools/*Tool.java
>
> In the commons sandbox the *Utils and *Tools was discussed and
> the java.util.* approach was taken where the radix is just postfixed
> with a plural - like java.util.Arrays, java.util.Collections,
> Something like DateUtils became Dates, XmlUtils -> XmlStrings,
> MathUtils -> Numbers or just Math (which has no plural form).
>
> How about such an approach?
That worked well for the Commons packages, but I'm not sure how well
it applies to the class names of the Java source files in the tools
component. If I've got it right now, these are context/pull tools.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-velocity-tools/tools/xdocs
DateTool.xmlMathTool.xml ParameterParser.xml ToolLoader.xml
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 4/4/02 3:07 AM, "Christoph Reck" <Ch...@dlr.de> wrote:
> "Geir Magnusson Jr." wrote:
>>
>> On 4/3/02 12:46 PM, "Jon Scott Stevens" <jo...@latchkey.com> wrote:
>>
>>> on 4/3/02 1:10 AM, "sidler@apache.org" <si...@apache.org> wrote:
>>>
>>>> tools/src/java/org/apache/velocity/tools/tools DateTool.java
>>>> MathTool.java ParameterParser.java ToolLoader.java
>>>> package.html
>>>
>>> Why is it that these fiels are in a tools/tools directory?
>>>
>>
>> Tools is the subpackage that holds all for the -tools project.
>
> yuk!?
> .../tools/tools/*Tool.java
>
> In the commons sandbox the *Utils and *Tools was discussed and
> the java.util.* approach was taken where the radix is just postfixed
> with a plural - like java.util.Arrays, java.util.Collections,
> Something like DateUtils became Dates, XmlUtils -> XmlStrings,
> MathUtils -> Numbers or just Math (which has no plural form).
Why is the plural of 'XMLUtil' -> XMLStrings ? And why did XML get demoted
to Xml?
> How about such an approach?
You think there will be enough tools for each bucket? I am afraid there
will be single-class packages, or when that wants to be avoided, things
misplaced...
One solution is to have
o.a.v.tools.components/<here is where tools live...>
If the name is so offensive...
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
"We will be judged not by the monuments we build, but by the monuments we
destroy" - Ada Louise Huxtable
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>