Hello,
"Geir Magnusson Jr." wrote:
>
> 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... :)
Okay.
> 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.
But clearly not always :)
> > 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.
> >> 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.
Okay. I see, it's just a simple container with meta info on the tool.
> You could also try a strategy where the tool itself decides - i.e. Pass it
> the ServletContext and let it place itself somewhere...
And the request.
> Nah...
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.
Like that idea. However, at first glance one might think the params are
property settings for the Escape tool rather than for the 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.
>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>
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>
-Bill
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
