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. the primary purpose of this 'managing' is to feed the current ViewContext to the appropriate tools on each servlet request. that's its purpose and that's why it resides in the view sub-package. if we change it to 'manage' tools for other environments, then we will be changing the primary purpose of the class to the point where it would no longer even belong in the same package. IMO that is a major conceptual change. further, i think that so far you have failed to make a good case for the varying environments being similar enough that this is a reasonable proposal. you say that most environments have a concept of 'request' and 'global' scopes. i disagree. most environments have some idea of *local* and 'global' scopes. the difference there is significant i think! 'local'/'global' refers to the visibility of a variable whereas the 'request'/'global' concept in a servlet environment is not one of visibility but of lifecycle! i remain unable to envision a reasonable tool management system that can appropriately handle such varying concepts, and i think it is unwise to try and make one. seriously, if you see some pressing reason to create a tool management system for another environment, then i recommend you implement it separately. if you still think the two can be unified into a more generic system, then feel free to do so. at least then you will have a better understanding of what is involved in tool management for other environments. at this point, i see no benefit to trying to abstract a generic tool manager from the current one. there is enough other work to be done on this project that is far more pressing. [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. (that's where they are put, and the point of implementing the interface in question is to make them sensitive to the 'context'). to say they support the servlet environment is quite broad. their specific purpose is to work with and upon the 'context'. i'm really not yet convinced that 'ContextTool' is a bad name. ViewContextTool is fine with me, and is very descriptive when you remember that the whole point of the interface has been to feed a ViewContext (a very servlet environment specific class) to the tool. > >>- 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! let me clarify. how does my ToolboxManager fail to gracefully handle those situations? the three scopes the tool manager handles are explicitly defined right there, and the 'valid scope checking' seems quite thorough to me. what's missing? [snip] > 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. again, i repeat that developers will be creating these tools and editing the toolbox.xml. the system i propose is really quite simple! if a developer is unable to figure out which of three scopes a tool he designed goes in, then they have far more serious issues to deal with. i do not see any need to baby them any more than my class does. [snip] > 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. redefining? i saw no redefining in your example code... but anyway, i still don't want to do it, and i still don't see how the ToolboxManager can know how to deal with arbitrary scope definitions!! the allowed scope definitions *must* be standardized somewhere accessible to the manager, or else they might as well be gibberish. [snip] > 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. this 'sanity check' *already* exists in the manager i wrote. at present it is resolved by logging an error message treating the tool as global. yes, the tool will likely fail, but it may at least be able to perform some functions. might as well give it a chance. i certainly don't think it hurts to have it there globally. > Ok, sorry for confusing you. I'll put this into code. But, not before the > weekend. if you really want to, then go for it. i'll take a look. just don't put the generic manager or interfaces in the view package that the current one is in. the view stuff is specifically for VelocityViewServlet stuff. Nathan Bubna [EMAIL PROTECTED] -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
