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 Thu, 02 May 2002 21:58:37 GMT
Gabe said:
> Nathan,
> I finally got around to study your latest proposal regarding the tool
> management. Overall I like the approach and think it is a good basis
> to move on.

well, it's a start at least.

> I'd like to make a few remarks/suggestions:
> - Your proposed DTD for the toolbox configuration makes good sense
> to me. The minor exception is that the 'scope' element seems to be
> missing. Or, am I missing something?

<!ELEMENT tool    (key,class,#PCDATA)>

a scope element would fall under the parsed character data here, right?  i
could be wrong; i haven't worked with DTD's much.

The reason i went with the open ended #PCDATA was to open the floor for
other tool attributes.  i don't expect scope to be relevant to all tool
types and therefore don't think it should not be a part of the general DTD.
i'd rather leave that to the specific application to determine.

> - In our past discussion Dan argued for a destroy() method
> as part of the ContextTool interface. This would be the place to do
> clean-up work or release resources. Your current proposal doesn't
> address this. What's your thinking on that.

actually, i did address it, but here it is again:

Nathan said:
> I can also envision someone creating a Poolable interface that offers a
> destroy()/reset() method, and implementing a PoolableToolInfo class that
> pools instances of Poolable tools in order to more efficiently implement
> getInstance().  I'm not convinced that these belong in this project
> keep it simple...

> - Here you add scope support to tool info. I have
> no problem with the implemenation of the class but think that the
> name is not the most appropriate one. In my view the concept of 'scope'
> is not limited to a servlet environment.

we've discussed this already rather extensively.  i'd rather not rehash it
all.  in brief summary, i wholeheartedly disagree that the "scope" concept
in the servlet environment is at all compatible with your suggested "scope"
concept in dvsl.  Remember, the whole point of my redesign was to allow for
many types of tools and toolinfos to go with them.  If you feel we need an
another ToolInfo for DVSL tools, then please implement it separately from
the ServletToolInfo.  It's really quite easy to do so.  You are trying to
hard to combine to very different concepts of 'scope', and the effort is

> In fact, no part of the class
> implementation is dependent on the Servlet API.

a class need not interface directly with the servlet api to be tied to the
servlet environment.

> Assume that I want to implement
> a toolbox manager for DVSL. In such an environment the scopes "request"
> and "application" make perfect sense. I see two possible resolutions:
>    - Rename the class to ScopedToolInfo
>    - Merge ServletToolInfo and ContextToolInfo and name the class
>      I actually don't see an advantage of having two classes instead of
>      Maybe I overlook something?

yes, if you don't want to use XMLToolboxManager directly, then you can
simply implement a DVSLToolInfo and extend XMLToolboxManager to handle your
dvsl tools as you desire.

and why on earth would you want to merge ServletToolInfo into
ContextToolInfo?!?  I'm sorry, but scope data does NOT belong in

> - ServletToolboxManager.getToolboxContext(): The instantiation of
>    session tools should be synchronized, otherwise it might happen that
>    the session-scoped tools are instantiated multiple times for the same
>    session.

this too has been discussed at length.  i think it's an incredibly paranoid
thing to do.  if done correctly, it wouldn't be too much of a performance
hit, but IMO, if the current design is problematic for a tool designer, it
is the fault of their tool design, not the fault of the toolbox manager.
anyway, you seem stuck on the idea, and i can't stop you from doing it.  so
do what you will, i'm tired of arguing about it.

> - 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. But,
>    the price is a problematic, underspecified, error-prone interface.
>    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 warn
them of their impending doom!  :-)  ok, maybe that's a little dramatic...

And where do you get this "problematic, underspecified, error-prone" stuff?
I see no problems (remember, i've already implemented and tested this code
and it worked great!).   I think it is exactly as specified as it ought to
be.  If we get any more specific, we not only lose simplicity, but also
flexibility.  One of my primary goals in rewriting things this way was to
make it easy to extend the ToolboxManager concept to other environments, and
I don't want to go making assumptions about the nature of those environments
and what init data they might use or need.   And as for "error-prone", huh?
i don't get that at all.

> Especially since we are not talking about very many
>    different init-cases. Currently we have identified two cases:
>      - Tools that need access to the servlet environment
>      - Tools that need access to the Velocity context

no, i counted three.  those that need the ServletContext, the ViewContext,
and just a Context.  and if you missed one already, what about all the
possible init data people might want that we haven't even thought of yet?
you were the one who challenged me to think bigger and get outside the
servlet/vvs box.  allow me to exhort you to do the same...

>    I really think we should go the extra mile and handle these two cases
>    with two specific interfaces.

I really think you're really wrong.  That extra mile will not only make
things more work for us, but it will make more work for others who want to
make use of this ToolboxManager concept.

> Nathan wrote:
>  > (Gabe, if you would really prefer to call this "ViewTool",  I can live
>  > it.  But i still think ContextTool will be more meaningful to users.)
> I really would prefer ViewTool. From talking to people, my experience
> is that ViewTool is more intuitive than ContextTool.

your experience perhaps, but not mine.  i've been lurking on the velocity
lists for well over a year and never heard the term 'view tool' until you
committed that change to the veltools project.

> Furthermore, there is nothing about these tools that is specific to
> the context.

?  so it doesn't mean anything to you that the whole purpose of these tools
is to be placed in the velocity context?

> Much more, they are specific to the view layer. If you
> consider a situation where the same tool is used with multiple view
> technologies, then 'context tool' seems quite inappropriate.

how so?  i think you ought to look up the word 'context' in an english
the tools are found in the velocity context, and the tools' behavior is
meant to vary based on contextual information either passed in by the
template, or thru the init() method.

i think you are afflicted with the misconception that the term 'ContextTool'
was derived from some connection to the javax.servlet.ServletContext.   let
me assure, that is not at all the case.

Nathan Bubna

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

View raw message