Gabe,
I'm going through the velocity-tools to try and understand them and try
to eventually contribute some tools that are complementary to them or to
add new methods, etc. The ToolLoader tool that you mentioned (doc at
http://www.teamup.com/jakarta-velocity-tools/tools/docs/ToolLoader.html)
and a comment made by Geir led me to think of some enhancements for
this. I'm going to explore these, but I thought I'd pass along some
ideas as I think of them.
I liked the simplicity of Geir's example where he used ("$tool =
new(<whatever>);") is some other scripting environment. I was thinking
that...
#set ( $newTool = $tool.load(<whatever>) )
might be a nicer syntax to use for loading tools.
(Oops...I just looked at the latest code. It looks like it is using that
syntax now.)
The <whatever> part the where I think some interesting possibilities
could be considered. I'm a bit wary of allowing access to any bean in
the classpath to the page designer as it currently stands (but it's
great for development). I think something like this might be nice:
#set ( $math = $tool.load( "math" ) )
#set ( $math = $tool.load( "math", arg0 ) )
#set ( $math = $tool.load( "math", arg0, arg1 ) )
#set ( $math = $tool.load( "math", arg0, arg1, arg2 ) )
The arguments (arg0, arg1, etc.) will depend upon the constructor
arguments of the class mapped to that tool name. Sometimes one tool may
be dependent on another tool or a value from the context:
#set ( $fmt = $tool.load( "format", $req.locale ) )
This might load a FormatTool that is initialized to the locale of the
HttpServletRequest with the VelocityServlet.
The first argument would be the name of the tool in the tool library
(toolbox). As I try to understand it, this is what you are also trying
to provide with the ToolboxManager in the Views sub project. There seems
to be some synergy between them. I'm still trying to figure it out so be
patient with me. :)
But assuming the ToolLoader tool was "informed" (by way of a constructor
argument) with where to look up the mapping of tool names to their
classes, then the tool name could be validated, class introspected and
tool instance constructed. A Map would be a generic way to do this
mapping allowing for additional utility classes to make this more
dynamic. Again, I think there's some synergy to the XMLToolboxManager
here. Is there an implementation of a utility class that loads a Map
from a Properties file or XML file and updates the contents if the file
changes or if it's told to look elsewhere? It would nice to add/remove
new tools to the system without restarting the application. It's an area
that I'm not familiar with but I know Velocity loads the libraries files
when they change if you want it to.
As for backward compatibility, the classname could be used instead of
the tool name, but the ToolLoader would "turn on" this capability when
constructed if it was desired. It would extend the tool by allowing the
same constructor arguments for the tool as well.
Additional ideas (still in gaseous form floating about my brain):
* Loading tools that do not have state and can be shared by different
threads (constructing only one instance).
* Loading tools from a pool so they can be checked out (or created),
reinitialized, and then automatically be checked back in after the
merge. I don't know how important this is to performance. (Are there any
Velocity performance metrics or comparisons or studies as to where any
issues are at?)
* ToolLoader method that would describe the tool and the methods that
may be invoked. (Actually this could be for any bean). Just a wrapper
around some reflection but it might be nice to have them be
self-documenting.
Anyway...I'll go play now. You were looking for some feedback and this
was the first chance I had to look a bit more closely.
bill
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
