On 3/15/02 1:56 AM, "Bill Burton" <[EMAIL PROTECTED]> wrote:
> "Geir Magnusson Jr." wrote:
>>
>> On 3/14/02 11:53 PM, "Bill Burton" <[EMAIL PROTECTED]> wrote:
>
[SNIP]
>>> 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.
>
> Yes, that's the idea. When specifying via XML, it shouldn't be necessary
> to include the context name with each tool declaration. Maybe using
> "contextname" would be better as it's what the property is currently
> called and it's more descriptive.
Right - and they would match, which is what I was getting at...
[SNIP]
>>
>> 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.
>
> Like that idea. However, at first glance one might think the params are
> property settings for the Escape tool rather than for the toolbox.
True, so we call it out explicitly :
<toolbox context="util">
<tool name="escape" classname="org.apache.velocity.tools.Escape">
<toolboxparam name="scope">Request</param>
<toolboxparam name="needsClasspath">true</param>
</tool>
</toolbox>
> I
> don't think a scope attribute is an issue because it would never be
> specified in a build.xml. It only might be an issue if a toolbox.xml
> could be loaded by the DVSL Task in which case it could be ignored.
Right - that's the idea. Things that aren't germane to your application are
ignored.
> From ToolboxManager:
> * <toolbox>
> * <tool>
> * <key>foo</key>
> * <scope>request</scope>
> * <class>com.mycompany.tools.Foo</class>
> * </tool>
> * <tool>
> * <key>bar</key>
> * <class>org.yourorganization.tools.Bar</class>
> * </tool>
> * </toolbox>
>
> The above is fine. But if it would not cause undue hardship, structuring
> it more like one would as atributes and nested elements in an Ant task
> brings some level of compatibility which is better than having two
> completely different syntaxes for no good reason. In Ant, the above might
> be declared within the DVSL Task as:
> <toolbox>
> <tool key="foo" scope="request" classname="com.mycompany.tools.Foo"
> />
> <tool key="bar" classname="org.yourorganization.tools.Bar" />
> </toolbox>
>
The problem here is that you know have inflicted this stuff directly into
the DTD. And if you wanted to add another, say a 'blofarb' for a different
app domain, you could now have to make it
<toolbox>
<tool key="foo" blofarb="1" scope="request"
classname="com.mycompany.tools.Foo" />
<tool key="bar" blofarb="2" classname="org.yourorganization.tools.Bar" />
</toolbox>
And of course, update the DTD. I don't think this is workable.
> Of course, scope wouldn't be valid within Ant. Also, the above could be a
> toolbox.xml loaded by DVSL or ToolboxManager. Right now the DVSL Task is
> using:
> <tool name="toolbox.tool.foo" value="com.mycompany.tools.Foo" />
> Deprecating "name" in favor of "key" would be more descriptive. So the
> DVSL version would look almost identical:
> <dvsl ... >
> <toolbox contextname="toolbox">
> <tool key="foo" classname="com.mycompany.tools.Foo" />
> <tool key="bar" classname="org.yourorganization.tools.Bar" />
> <tool key="greeting" value="Good morning!" />
> </toolbox>
> </dvsl>
But I can't then have a universal toolbox that I throw into everything.
That itself may be unreasonable - that no one would do that anyway, in which
case we should bag the discussion, and have the toolbox manager, which
really isn't that complicated, just be custom for each app. Otherwise,
pushing for a univeral DTD would be nice.
geir
--
Geir Magnusson Jr. [EMAIL PROTECTED]
System and Software Consulting
The bytecodes are language independent. - Sam Ruby
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
