Nathan Bubna wrote:
... >>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. I am not suggesting to implement it but to take into consideration that there are other environments where tool support is desireable. DVSL ant is a specific example of such a non-servlet environment were tool support would make sense. Seems my English is lacking precision :-( >>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. Yes! That is a very good point. The primary gool is to make tools reusable. > also, let's not get so caught up in what's > 'possible' that we lose touch with what's 'reasonable'. I think it is worth to develop a little conceptual understanding of what relevant aspect of tools are. Let's take logging. If we define a way to pass a logger we want to make sure that this works in different environments, not just a servlet environment. ... > > 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. Request and global scopes apply to most environments I can envision. The ToolboxManager certainly would have to be adapted but hopefully not conceptually redesigned. >>- 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. 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? >>- 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 >> - Check that a valid scope is chosen >> > > is there really a need for more explicitness? what situations are you > trying to prevent? For example the two situations listed just above! > 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? I don't want to prevent variable-scope tools. I bought that idea. But I want to prevent that a tool that needs to be in request scope ends up in global scope and fails, etc. etc. .... >>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. I thought my two code examples showed this :-) The benefit of redefining the scopes in each tool are that you can give the ToolboxManager hints about what scopes are possible, multiple if applicable. >>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. If a tool is defined to be in request scope but doesn't implement any known interface the ToolboxManager won't be able to pass any data and the tool likely won't work properly in global scope (that's an example of a sanity check I meant). The best resolution is probaly to not load the tool and log an error message. >>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. Ok, sorry for confusing you. I'll put this into code. But, not before the weekend. Gabe -- Gabriel Sidler Software Engineer, Eivycom GmbH, Zurich, Switzerland -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
