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 Fri, 03 May 2002 16:47:08 GMT
Gabe said:
> Ok, I got your points. I do not agree with all your arguments but these
> point of disagreement are mostly related to possible future uses of the
> software in other environments. I think that the current proposal supports
> all the key features that we need to move on. Feedback from users and real
> applications will tell us in the future if all the design decisions were
> right.
> The one thing that I really would like to get fixed is the synchronization
> of the instantiation of the session tools (see my points below).


> I propose that you send me all the modifed files and I will
> then check them in. Please make sure that the JavaDoc is reflecting the
> latest design.

sure, the synchronization change should only take a second.  bear with me on
the javadoc if i miss something.
so what is the call on ViewTool vs. ContextTool?  no one else has offered an
opinion or vote so far, and you and I aren't in agreement.  i guess if no
one breaks the tie, i'll go ahead and change my proposed code to use
'ViewTool' in deference to your committer status.

> >>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
> I am not talking about the pooling of tools. There are two different
> here. One issue is the need to release resources after the tool has been
> A proposed solution was to have a destroy() method. Dan reported a need
> that (it was part of the original design but removed later). The other
> is the pooling of tools for efficiency. We agree that this is not high
> right now.

what is "need to release resources"?  i was only ever taught as a java
programmer.  i don't know what that means. :-)  (i'm kidding of course...
well... sorta :-)
you say this is a problem "after the tool has been used", but if we no
longer hold a reference to the tool, the garbage collector should release
the resources.  why hold on to the tool reference if not for pooling?  that
sounds like a fairly unique case, and should probably just be implemented by
the designer.  the only standard situation i'm familiar with that should
have this destroy() functionality is pooling, but maybe that's just my
ignorance.  no matter, we'll get to this later.

> >>Nathan wrote:
> >> > (Gabe, if you would really prefer to call this "ViewTool",  I can
> >> with it.  But i still think ContextTool will be more meaningful to
> >>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
> > lists for well over a year and never heard the term 'view tool' until
> > committed that change to the veltools project.
> So you can't live with it? :-)
> > >>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
> > is to be placed in the velocity context?
> I claim that the purpose of these tools is not to be placed in the
> Velocity context but to provide some utility to the view layer,
> whatever this view layer is. :-)

heh.  now we're really pushing the boundaries :-)  this is, after all, a
velocity sub-project...

> I personally use some of my view tools in JSP and Velocity. I am
> sure many Struts users would want to do the same. The name context tool
> doesn't really have a meaning outside of Velocity. But, many view tools
> have very much a purpose outside the Velocity environment. So, we can
> use our own terminology or use something that has a meaning in other
> environments as well. Another term I occasionally read on the Struts
> list is "view helper"
> I think enough has been said. Let's get this code into the repository.
> I want to get the Struts stuff out to Struts users so that we can
> gather some real feedback.

I'll try and get the revised code out to you today, but it might be first
thing monday.  I'll send patches for the existing tools as well since i've
already changed those too.

Nathan Bubna

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

View raw message