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. Was rather puzzled
that the DVSL toolbox was just a properties file rather than being XML
based.
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" />
> 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.
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.
-Bill
> [SNIP]
>
> >
> > [snip]
> >>> perhaps you would prefer ViewContextTool to emphasize the connection to
> > the
> >>> ViewContext class.
> >>
> >> No that doesn't really hit it. IMHO the most relevant aspect is that
> > ContextTool
> >> has special support for the servlet environment. Your point about a
> > potential
> >> confusion with javax.servlet.ServletContext is good, though. How about
> >> ServletTool?
> >
> > no, because then you lose the whole point that these are 'context' tools.
>
> Velocity Context Tools
>
> --
> 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]>
