Gabe said: > Isn't the scope of a tool given by its design? I mean, if a tool requires > access to request data its scope is obviously 'request', etc. So, why allow > the user to configure something that is already fixed by the design of the > tool? Maybe my imagination is too limited?
hmm. i would say that the scope of a tool most certainly can and should be closely tied to its design, but i can envision situations where a tool can be designed to work in multiple scopes. in these situations (and i think generally as well), being able to set the scope of a tool in the config file can be both useful and more efficient. at present, the tools we've talked about are all request oriented or global (aka static). in the velstruts app i've developed, one of the tools i wrote is only session sensitive. it cares neither about requests, nor is it static. for this tool, i need to implement ContextTool (or something like it in order to get access to the session, but it is a waste of time to get a new instance for each request. i would like to be able to configure the toolbox so that a new tool is created only per session. my proposal would handle this efficiently, without having to check the 'design' of every tool on every request. as for the scope being 'fixed by the design', i don't think that must necessarily be true. if my proposed behavior is accepted, i would happily make DateTool implement ContextTool so that instances returned by 'getInstance' would look for a Locale in the request or session to use instead of the default. that way, those developers who wish to use DateTool as global (statically) or request scope may simply specify the desired scope in the config file. > By implementing specific interfaces we can give the tool manager hints about > how to handle the tool. If a tool doesn't implement any interface, some > default behaviour would be applied. yes, but even if we have a different interface for every scope (or at least the non-static scopes), it is inefficient to check every tool for the appropriate hints on every request. it is more efficient and gives greater flexibility if we specify scope aforehand. at the very least i would want the toolbox manager to check those 'hints' upon initial loading of the toolbox and maintain the three lists of tools as i proposed. > You mention Turbine's PullService: Can you show some cases where it makes > sense to let the user choose the scope of a tool? user?! i would hardly call editing the toolbox config the job of a user! i would expect a developer would typically be responsible for that. i'd even be surprised to see a designer messing with that. in any case, i would suggest that we make the default scope (the setting if no scope is specified in the config) be request. that is essentially what the current behaviour is, and that way the worst that happens is that getToolboxContent is more inefficient than need be. i'm writing the code for this right now so you can see it. i'll post as soon as its ready. Nathan Bubna [EMAIL PROTECTED] -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
