Gabriel Sidler said: [...] > > it is an idea i considered briefly, but decided against for several reasons. > > for one, MathTool is completely static, there is no point or benefit to > > implementing ContextTool or any other tool interface. > > > Exactly in the case of an all static tool it is important to give > the tool manager a hint that it does not need to recreate instances > for each request. So, the proposed isStatic() method would allow a > smart tool manager to use one instance for the entire runtime. > How else do you distinguish between all static tools and non-static tools?
why do you need to distinguish? in the current ToolboxManager algorithm, if a tool doesn't implement ContextTool, then the same instance is *already* automatically used for the entire runtime. i don't see how this is beneficial. i know i've certainly not run into a situation that begs for it. if you have, please enlighten me. > > but the main problem > > i have with implementing ContextTool is that i do not use these tools solely > > with the VelocityViewServlet. > > Actually, the ContextTool interface is not desiged to be used with > VelocityViewServlet only. It should be useful in any circumstance > where you work with Velocity and tools. For example, I am thinking > about DVSL. uh, not so fast. implementing the ContextTool interface is completely useless for a pull tool used in Turbine. i suspect the same would be true with other frameworks. there is no functionality built in to deal with ViewContexts or 'init' factory methods. Turbine already has its own system for managing tools. > > in fact, they were originally written to be > > used in a Turbine/Velocity web app and are still primarily used there. so I > > don't think there is any benefit to tying these tools to the view servlet. > > As said, the interface shouldn't tie the tools to the VelocityViewServlet > at all. If the current draft does, we should change it to achive this goal. i should be more specific. the interface ties implementing tools to the ViewContext class and a specific pattern of tool management that may not be desired, needed, or useful when working with the tool in a different framework. Nathan Bubna [EMAIL PROTECTED] -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
