velocity-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gabriel Sidler <>
Subject Re: [veltools] proposed change to ToolboxManager
Date Thu, 14 Mar 2002 10:51:58 GMT
Nathan Bubna wrote:

> Gabe,
> ok.  here's what i've done with ToolboxManager. (if you want this as a
> patch, let me know)

Hi Nathan,
Thanks for the code. I like your idea and implementation. We may look
at things from different angles but actually we are not far apart.

There are a few things I'd like to improve: (some of the feedback
applies to the design of the ToolboxManager and the ContextTool in
general, not your proposal specifically, but since we are at it...)

1) (Watch! I am using your argument :-)) In my opinion the design and
implementation of the ToolboxManager is currently geared too much
towards the servlet environment. A goal of the whole tools effort
is to create the mechanisms to work with context tools in any kind
of environment, thereby fostering the widest possible reuse of context
tools. A servlet environment is obviously one of the first places to
use tools, but there are others. I personally would like to see DVSL
retrofitted with this toolbox support. I am sure there are many other
non-servlet environments where support for context tools is desired.

I'd like to propose that we consider the case of the ant DVSL task in
this  discussion, just for the sake of forcing us to think about
other environments and reuse of tools. (Are you familiar with it?
The ant DVSL task basically allows to batch-process a set of XML
files to text files using a style sheet. The style sheet is written
in Velocity script.)
One context tools that would be useful in the case of the ant DVSL
task is a tool that gives access to the ANT environment, for example
the name of the current template in processing, the name of the style
sheet, etc. etc.

So the challenge is to come up with a concept that is easily adapted
to other environments and allows widest possible reuse of tools. This

- Choose a design that can easily be adapted to work with other/
additional classes of tools (potentially having other scopes
and other init data)

- Select appropriate names (ContextTool is an an example of a bad
name in this respect because it implies that it is some kind
of super context tool. More accurate would be ServletContextTool)

- Make the contract between context tools and the tool manager
explicit so that sanity checks can be performed:
     - Check that a particular tool manager can handle a particular
       class of tools or report error
     - Check that a valid scope is chosen or report error

- Make the implemenation such that it is obvious where to add
support for other/additional classes of tools.

The current implementation of ToolboxManager doesn't need to change
much to be compatible with these goal. It's mostly about the way we
think, name and document things. Below a few specific points:

2) I propose that we rename the current interface ContextTool to
ServletContextTool because it is really geared towards a servlet
environment. This allow for other classes of context tools.

3) In your draft there is an implicit contract between a context tool
and the tool manager regarding the scopes. I'd like to make this contract
explicit. This makes things clearer (because more explicity) and allows
for sanity checks when loading a tool. One way to do it is to add
the definition of the scopes to the ServletContextTool interface:

public interface ServletContextTool
    // Define the possible scopes
    public static String REQUEST;
    public static String SESSION;
    public static String GLOBAL;

    public Object getInstance(ViewContext context);

An actual implementation of a tool would then define the values of the
scopes, for example:

public class ErrorsTool implements ServletContextTool
     // Define the possible scopes
     public static String REQUEST = "request";
     public static String SESSION = "session";
     public static String GLOBAL = null;

This allows a ToolboxManager implementation to verify that the tool is added
to a valid scope. In the above example a tool could only be added to request
or session scope. Any other scope would produce an error message and not load
the tools. This prevents magic behavior due to misconfiguration of the scope.
Furthermore, the interface
establishes the strings to be used in toolbox.xml to identify the scopes. It
is important that the tool creator defines these strings because he is the
one that writes the documentation for the tool.

4) Remove the definition of the scope strings from ToolboxManager and
    instead work with the scope strings defined by a particular tool

5) Explicitely document in the ToolboxManager the default treatment of tools
    that do not implement any of the known tool interfaces.

6) Explicitely declare in the ToolboxManager the classes of tools that it
    can handle and what happens with tools of unknown classes.

7) Structure the code of ToolboxManager such that it becomes obvious where
    to add support for other classes of context tools.


Gabriel Sidler
Software Engineer, Eivycom GmbH, Zurich, Switzerland

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

View raw message