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, 13 May 2002 15:25:27 GMT
Sean said:
> In message <058701c1f7a9$62b669a0$>, Nathan Bubna
> <> writes
> >> well how about both interfaces implementing a common base interface
> >> has all the methods bar init?
> >
> >heh.  the "init" method is the only method at present.
> oh, okay - didn't take a close enough look. In that case two interfaces
> seems very reasonable, they're both doing different things. And a tool
> that wanted to be able to live in both scopes could implement both
> interfaces ...

I agree--two interfaces does seem very reasonable.  I could probably even
live with three interfaces if Turbine took that road.  However, i don't
think two or three interfaces will be enough.  One of the goals we've had
here is to create generic velocity tool/data management.  We want to create
a toolbox system that can be easily used to populate the context for a
variety of different environments using velocity.  So far, yes, we have only
really worked on a toolbox for the servlet environment where we can easily
get by with just two or three interfaces (as Turbine could and perhaps
should).  But when you look outward to using this stuff for dvsl or other
environments, having interface methods like
init(javax.servlet.ServletRequest) become cruft and the toolbox code we've
written is useless to them.  In contrast, by keeping the tool interface and
toolbox manager as generic as possible, we allow them to be used with some
consistency across a variety of environments.  I think the compile-time
ambiguity introduced is perfectly acceptable in light of the benefits.

Nathan Bubna

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

View raw message