velocity-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nathan Bubna" <>
Subject Re: [Veltools] ToolboxManager (round 4 :-)
Date Mon, 06 May 2002 21:43:44 GMT
Sean said:
> >>>- I am quite uncomfortable with the proposed init method of
> >>>ContextTool.
> >>>
> >>>     public void init(Object initData);
> >>>
> >>>   This is virtually moving us back to C-times where we worked with
> >>>   and suffered from all kind of related problems. The interface is
> >>>   specified through the documentation. Yes, this approach
> >>>   keeps the interface between tools and the toolbox manager simple.
> >>>   the price is a problematic, underspecified, error-prone interface.
> >>>
> >> That's too high a price.
> >>>
> >>  Really?  I'll be sure to pass that on to Turbine-land where this has
> >>worked
> >> great for their PullService for quite some time now.  Someone should
> >> them of their impending doom!  :-)  ok, maybe that's a little
> >
> >Well, I don't think this pull tool interface it their masterpiece of
> >engineering. It's a working compromise.
> As co-author of the Turbine PullService, I have to agree with Gabe here.
> I was never completely happy with this aspect of the API, and really
> only agreed to implement it because there was a precedent elsewhere in
> the Turbine code (can't remember where now).

heh, figures.  thanks for the info.

> If you can find a better approach, use it! (And maybe suggest the
> improvement back over in Turbine-land).

well, it looks like we've only got two suggestions so far.  one is to create
a new virtually identical interface for each type of init data we can come
up with, and the other is to use one interface that takes an Object.

any lateral thinkers out there got a better way?  given the choice between
the two, i definitely prefer the single-interface.  the fact still remains
that it has worked well for me in our turbine apps, and it is the simpler
solution.  i can handle a little ambiguity if it will give me greater
flexibility.  in Turbine i guess i can see more reason to go specific
interfaces (for session/User, request/RunData, etc.), because the
PullService is explicitly tied into Turbine and the servlet environment.
Since we are trying to keep the toolbox management accessible to DVSL and
other environments beyond servlets, I'm much less eager to start down the
path of adding a new tool interface everytime someone has a new class they
want to use to initialize their tools.  I really can't see how we can
generalize the ToolboxManager without having a generic tool interface.  i.e.
it doesn't make much sense to have a ToolboxManager interface with a
getToolboxContext(Object initData) if the tool interface doesn't have a
init(Object initData).   we're certainly not going to add a new
getToolboxContext(SomeClass sc) method to ToolboxManager for each type of
initData, so we must either find an entirely different way to generalize
management tools, keep the tool interface matched to the ToolboxManager
interface as i proposed, or forget generalizing the tool management and go
back to developing wholly independent managers for each environment.

Nathan Bubna

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message