Geir said:
[...]
> >> public static boolean isStatic()
> >
> > -1
> > ick! i don't see the point of this. if a tool is completely static, it
> > shouldn't be implementing the ContextTool interface. my understanding
is
> > that ContextTool is for tools that are request/session/application
> > sensitive. if a tool is static, it has no use for such stateful objects
and
> > therefore it is a waste of time to implement ContextTool or anything
else.
> > the view servlet should just use the same instance of static tools for
all
> > requests.
>
> You are right - I didn't think about it that way - my thoughts surrounding
> this really had to do with lifecycle - and I think the right name here is
> 'single instance' (note I avoided the word 'singleton')
>
> When you list your tools in the configuration, you can indicate if the
tool
> is a single instance or not, -> the toolmanager reuses a single instance
in
> each context, or must make a fresh instance for each.
>
> That's the important aspect here, or believe so, because it means if you
> have some heavy tools that do an incredible amount of stuff once, then you
> can denote them as 'single instance' in the config, and not worry that you
> get hammered with each use.
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.
Nathan Bubna
[EMAIL PROTECTED]
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
