Nathan Bubna wrote: > 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.
I am little concerned that we make configuration more compliated than necessary, but if there there is a real benefit for it... > 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. What does this tool? I am curious because I couldn't think of any such tool. > 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. Well, checking of the 'design' should happen once at loadtime. > 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. I see your point in theorie. I am just not convinced yet that it addresses are real need. I cannot imaging a real-world tool where the scope it not fixed by the design of the tool. > > >>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. Of course, there shouldn't be any checking at every request. >>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. Well, in one of your last mails you convinced my of the opposite ;-) Assuming request scope might seem to be safe default behavior, BUT if a tool doesn't implement any interfaces it won't be able to get an parameters passed from the tool manager. If it doesn't get any parameters, it doesn't interact with the environment. Isn't it pretty safe to assume that in such a situation the tool is global? With my current understanding I would vote for global scope as default. > 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. Ok, I'll wait for your code and then will go from there. Gabe -- Gabriel Sidler Software Engineer, Eivycom GmbH, Zurich, Switzerland -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
