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. 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. A great example of application differences are scopes... Darn important (sadly) in the servlet environment, but utterly irrelevant in Ant-driven tasks. [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]>
