Nathan Bubna wrote: [...]
> well, since we're talking about tool configuration, lifecycle, etc., it's > given me an idea. > this is off the top of my head, but i guess you can consider this something > of a counter proposal of sorts to Gabriel's proposed ContextTool changes... > > one of things i appreciate about Turbine's tool management system > (PullService) is the ability to specify the scope of my tools (session, > request, global). i think something similar to that would be relatively > easy to implement with the ToolboxManager. all we would need to specify the > desired scope for our tools in the toolbox.xml as such: > > <toolbox> > <tools> > <object> > <contextkey>link</contextkey> > <scope>request</scope> > <class>...LinkTool</class> > </object> > <object> > <contextkey>math</contextkey> > <scope>global</scope> > <class>...MathTool</class> > </object> > </tools> > </toolbox> > > in ToolboxManager we'd load three lists of tools, instead of one. the > global tools would be initialized immediately, and then on each call of > getToolboxContext, we would > 1. add the initialized global tools to the ToolboxContext > 2. check the session for a list of stored session tools > if the list is not there, > initialize any session tools > store them in a list in the session > add the initialized tools to the ToolboxContext > if the list is there, > add the already initialized tools in it to the ToolboxContext > 3. initialize and add all request tools to the ToolboxContext > > hmm, i probably should find a better word than "initialize" in the above > proposal, but my brain is failing me on that. so i guess i need to explain > that tools which wish to be "initialized" need to implement ContextTool. > they would be "initialized," by calling 'getInstance' or 'init' or whatever > we call it, and using the "initialized" tool that method returns. > otherwise, the instance created during the first loading of the toolbox will > be used. > actually, if that's the case, then we ought to insist (and enforce) that > session and request tools must implement ContextTool. > > let me know what you guys think about this, but i'm probably gonna implement > it myself first thing tomorrow to see if i really do like this idea. if i > do like it, i'll be more than happy to share the changes i make. 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? 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. You mention Turbine's PullService: Can you show some cases where it makes sense to let the user choose the scope of a tool? Gabe > > Nathan Bubna > [EMAIL PROTECTED] > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > -- Gabriel Sidler Software Engineer, Eivycom GmbH, Zurich, Switzerland -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
