Gabe said: [snip] > 1) (Watch! I am using your argument :-)) In my opinion the design and > implementation of the ToolboxManager is currently geared too much > towards the servlet environment. A goal of the whole tools effort > is to create the mechanisms to work with context tools in any kind > of environment, thereby fostering the widest possible reuse of context > tools. A servlet environment is obviously one of the first places to > use tools, but there are others. I personally would like to see DVSL > retrofitted with this toolbox support. I am sure there are many other > non-servlet environments where support for context tools is desired.
:-) i was arguing for tools being easy to use in other servlet environments; this is a whole new ball of wax. i'll listen though... > I'd like to propose that we consider the case of the ant DVSL task in > this discussion, just for the sake of forcing us to think about > other environments and reuse of tools. (Are you familiar with it? > The ant DVSL task basically allows to batch-process a set of XML > files to text files using a style sheet. The style sheet is written > in Velocity script.) > One context tools that would be useful in the case of the ant DVSL > task is a tool that gives access to the ANT environment, for example > the name of the current template in processing, the name of the style > sheet, etc. etc. i'm not at all familiar with DVSL or writing Ant tasks. could be interesting to learn, but my plate is pretty full at the moment. i probably won't be to useful on something like this. > So the challenge is to come up with a concept that is easily adapted > to other environments and allows widest possible reuse of tools. This > involves: widest possible reuse of tools is one thing, widest possible reuse of the toolbox support is another. also, let's not get so caught up in what's 'possible' that we lose touch with what's 'reasonable'. at this point, the whole velocity-view package *is* designed to support and implement the VelocityViewServlet. i'm ok with putting some of the more generic tools like DateTool or MathTool outside of the view package, but the toolbox stuff at this point is intimately (perhaps inextricably) woven to the view package and the servlet environment. to create a more generic toolbox system would be basically creating an entirely new thing. at this point i think it may be best to look at this concept as a separate project. > - Choose a design that can easily be adapted to work with other/ > additional classes of tools (potentially having other scopes > and other init data) does the concept of 'scope' even apply to something like a DVSL task? and even if their is some 'scope' type think involved, is it at all compatible with a servlet's concept of 'scope'? i have a hard time seeing how one toolbox solution will fit such disparate functions. i need some more concrete examples of what you have in mind. > - Select appropriate names (ContextTool is an an example of a bad > name in this respect because it implies that it is some kind > of super context tool. More accurate would be ServletContextTool) hmm. not sure i like ServletContextTool. it makes me think of javax.servlet.ServletContext which is not a connotation we want the proposed interface to carry. if you're really that unhappy with 'ContextTool', perhaps you would prefer ViewContextTool to emphasize the connection to the ViewContext class. > - Make the contract between context tools and the tool manager > explicit so that sanity checks can be performed: > - Check that a particular tool manager can handle a particular > class of tools or report error > - Check that a valid scope is chosen or report error is there really a need for more explicitness? what situations are you trying to prevent? IMO the 'sanity checks' already implemented in my ToolboxManager are sufficient. remember, it will almost certainly be developers writing this tools and configuring the toolbox.xml. is there really a good reason to prevent variable-scope tools like the altered DateTool i proposed? > - Make the implemenation such that it is obvious where to add > support for other/additional classes of tools. > > The current implementation of ToolboxManager doesn't need to change > much to be compatible with these goal. It's mostly about the way we > think, name and document things. Below a few specific points: doesn't need to change much?! really? maybe i'm just not getting it. got any code for that to show me? i understand that better than emails usually. [snip] > 3) In your draft there is an implicit contract between a context tool > and the tool manager regarding the scopes. I'd like to make this contract > explicit. This makes things clearer (because more explicity) and allows > for sanity checks when loading a tool. what things does it make clearer? the scope of a particular tool? i don't see the need for any more 'clarity' than what i've proposed. what if a developer wants to design a tool that can be used in multiple scopes? and again, what sanity checks do you think are missing? sorry, i'm just not following. [snip] > 4) Remove the definition of the scope strings from ToolboxManager and > instead work with the scope strings defined by a particular tool > instance. ick. how is that supposed to work? if there are no standardized scope strings, how does the ToolboxManager know how to treat a tool? i don't get this. and even if it would work, i don't like the idea of having to do the extra work of re-defining scopes in every tool i write. > 5) Explicitely document in the ToolboxManager the default treatment of tools > that do not implement any of the known tool interfaces. and what do you propose to do with unidentifiable tools? right now they're treated as static. i thought we agreed there's nothing else that can be done if we have no way to pass information to them. > 6) Explicitely declare in the ToolboxManager the classes of tools that it > can handle and what happens with tools of unknown classes. what do you mean 'explicitly declare'? we can always make the comments and javadoc more explicit and detailed, is that what you mean? maybe it's just too early in the morning for me, but i'm really not following. if you could write up some working code for all this, it would probably help matters. Nathan Bubna [EMAIL PROTECTED] -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
