On 3/14/02 11:53 PM, "Bill Burton" <[EMAIL PROTECTED]> wrote:
> Hello,
>
> "Geir Magnusson Jr." wrote:
>>
>> On 3/14/02 7:11 PM, "Nathan Bubna" <[EMAIL PROTECTED]> wrote:
>>
>>> Gabe said:
>>> [snip]
>>>> The ToolboxManager certainly would have to be adapted but hopefully
>>>> not conceptually redesigned.
>>>
>>> well, i don't think this is simply a matter of 'adapting' the
>>> ToolboxManager to fit other environments. it was written to 'manage' tools
>>> for the VelocityViewServlet.
>>
>> This historical revision is killing me :)
>>
>> It was originally written for DVSL... And yes, it has evolved in DVSL to
>> something better, and we figured out that (surprise surprise) application
>> environments are different, and have things you can take advantage of. For
>> example, Bill did some nice work in allowing tools to be expressed directly
>> in the build.xml for Ant along with a toolbox file - the result being
>> greater flexibility and convenience.
>
> Thanks, Geir! I was wondering about the history of the View Toolbox vs.
> the DVSL one. I had been under the impression that the View Toolbox was
> implemented more recently because it was XML based.
It was implement more recently... :)
And I may be confused - both were going on at the same time. However, the
idea is a pretty old one - I think Texan has the same notion as well.
My point, however badly made, was just that the toolbox concept is pretty
general, and each application domain will have different requirements, in
format of tools, loading, etc so if you want to use it in more than one
place, it must be general.
> Was rather puzzled
> that the DVSL toolbox was just a properties file rather than being XML
> based.
I'm fundamentally lazy.
> This discussion has gotten me to think that the DVSL toolbox could use
> some enhancements so the XML in the DVSL Task would be more expressive,
> allowing the context name to be specified and some other enhancements so
> istead of dealing with property names, it would be XML attributes and
> elements, i.e.
> <toolbox context="util">
> <tool name="escape" classname="org.apache.velocity.tools.Escape" />
> <tool name="version" value="0.42" />
> <tool name="majerversion" type="integer" value="1" />
> </toolbox>
> <!-- Load more tools via a properties (or XML?) file -->
> <toolbox file="tools.properties" />
>
Ya, sure. That would be nice. I assume that the
context="util"
Is the toolbox name? If so, we might want to make it the same if via XML or
properties -> lets choose one.
>> So I would suspect that the concept of tools is universal, but the
>> application requirements may dictate or allow non-portable things. That's
>> why I am suspect of any kind of magic interfaces on the tools in general,
>> although I think there is good use in specific instances.
>
> Agreed.
>
> Suggest the Toolbox be flexible and let the developer load whatever class
> into whatever scope they think it should live. There don't need to be any
> constraints on implementing some interface. However, if a particular
> interface was implemented that the Toolbox understood, it could perform
> further initialization of properties on that tool and/or load it into a
> particular scope.
That's the point of the ContextTool inteface.
You could also try a strategy where the tool itself decides - i.e. Pass it
the ServletContext and let it place itself somewhere...
Nah...
>
> Also, if this ToolboxFactory class was configurable it could be extended
> with a different implementation that may have different or additional
> policies for loading tools.
>
>> A great example of application differences are scopes... Darn important
>> (sadly) in the servlet environment, but utterly irrelevant in Ant-driven
>> tasks.
>
> Despite that, the XML used to declare tools for the DVSL Task could be
> made nearly the same as that for Velocity Context tools. The only
> difference being that there would be no way to specify a scope attribute
> to the DVSL Task.
Right - the scope would be pointless in Ant-land. So do something where the
application specific hints are as name/value pairs :
<toolbox context="util">
<tool name="escape" classname="org.apache.velocity.tools.Escape">
<param name="scope">Request</param>
<param name="needsClasspath">true</param>
</tool>
</toolbox>
So if a toolbox impl understands the param hint, it uses it. Otherwise just
ignores.
--
Geir Magnusson Jr. [EMAIL PROTECTED]
System and Software Consulting
The question is : What is a Mahnamahna?
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
