[veltools] proposed change to ToolboxManager

[Nathan Bubna <de...@hotmail.com>]

Gabe,

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

there's a couple things you'll probably notice.

first, i haven't touched the subject of logging yet.  i still need to think
about that.  let's just work on one thing at a time for now.

second, i changed the format of toolbox.xml slightly.  i think it is equally
informative and yet much cleaner like this.  any thoughts from you?  i
wasn't around when this project started, so i may be unaware of some reasons
for the way things were before.

other than that, the class is pretty much what i described as my goal in
previous emails.  it handles all three scopes (request, session, global)
efficiently, and also allows developers to specify the scope of their tools
in the config file.  also, it forces request and session tools to implement
ContextTool.

i tried it out on my velstruts app with FoodlistTool et al, and it worked
like a charm.  so, let me know what you think i guess.

Nathan Bubna
nathan@esha.com

Re: [veltools] proposed change to ToolboxManager

[Nathan Bubna <na...@esha.com>]

Gabe said:
> Nathan,
> Would you please remind me again why we need configurable scopes
> for tools? Scopes are important but why do they need to be configurable?
> Can you show a concrete example or two of tools where the scope is not
> fixed by the design of the tool but rather should be configurable
> by the application developer?

<sigh>must i repeat myself?</sigh>  :-))
the example i gave previously was regarding the DateTool i submitted.  if
configurable scopes are allowed, it may be beneficial to alter DateTool to
implement ContextTool (or whatever we end up calling that interface).   I
can easily envision a single DateTool class that can function appropriately
according to the scope for which it was designated.  if a developer wished
to use it statically across the application, it would be constructed using
the default constructor and thus reflect the locale of the application.  if,
however, a developer wished to have the tool reflect the locale for a
request, they would designate it as 'request' scope in the toolbox.xml and
the toolbox manager would then use the ContextTool interface to obtain
instances of the tool.

again, i readily concede that examples such as this will probably be the
exception rather than the rule and certainly developers can always extend
tool classes to implement different scope designs, but i believe this is a
nice feature and a more elegant solution to using tools in multiple scopes
than forcing developers to extend a tool they wish to use in a different
scope.

the other reason (and this is perhaps the larger one) i prefer to specify
scope in the configuration file, is that it is more informative that way and
requires less special knowledge.  if scope is only set by the interfaces a
tool implements, one must then look at the source for each tool and know
which interface is for which scope.  so even should supporting
variable-scope tools be voted down, i think it may still be beneficial to
use the config file to confirm the desired scope of tools.

i suppose the last reason i think we should support variable-scope tools is
simply "why not?"  seriously, it would take at least as much work (if not
more) to enforce fixed-scope by design as it took me to implement
configurable scope in my code.  is there a good reason to force scope to be
fixed by design?

Nathan Bubna
nathan@esha.com


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [veltools] proposed change to ToolboxManager

["Geir Magnusson Jr." <ge...@optonline.net>]

On 3/21/02 1:17 PM, "Gabriel Sidler" <si...@teamup.ch> wrote:

> Nathan,
> Would you please remind me again why we need configurable scopes
> for tools? Scopes are important but why do they need to be configurable?
> Can you show a concrete example or two of tools where the scope is not
> fixed by the design of the tool but rather should be configurable
> by the application developer?
> 
> I just cannot think of any real uses cases and start wondering
> whether we are addressing a non-issue here.

How about a simple resource bundle?  Why is the scope of where that should
be placed fixed?


-- 
Geir Magnusson Jr.                                      geirm@optonline.net
System and Software Consulting
"Whoever would overthrow the liberty of a nation must begin by subduing the
freeness of speech." - Benjamin Franklin



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [veltools] proposed change to ToolboxManager

[Gabriel Sidler <si...@teamup.ch>]

Nathan,
Would you please remind me again why we need configurable scopes
for tools? Scopes are important but why do they need to be configurable?
Can you show a concrete example or two of tools where the scope is not
fixed by the design of the tool but rather should be configurable
by the application developer?

I just cannot think of any real uses cases and start wondering
whether we are addressing a non-issue here.

Gabe




--
Gabriel Sidler
Software Engineer, Eivycom GmbH, Zurich, Switzerland


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [veltools] proposed change to ToolboxManager

[Nathan Bubna <na...@esha.com>]

Gabe said:
> I am not trying to create a generic tool management BUT generic tools! You
> think too far. All I propose are some minor changes to (hopefully) allow
> widest possible reuse of tools and make sure that tool handling is safe
> and efficient.

it's already very easy to create a generic tool!  just write a class with a
public default constructor. if you haven't been talking about making tool
management more generic, then i'm very confused. (and in my experience,
that's a distinct possibility :-)

>  In addition I want to get the naming right so that working
> with tools is intuitive.

+1

> In your current proposal you have a contract between tool classes and the
> toolbox manager that is defined in the documentation. I'd like to define
> this as part of a Java interface because this allows checks that
everything
> is well and right

i'd rather not hard-code this stuff into an interface.  at least not any
more than i already did in my submitted code.  i really don't think that's
necessary, and i strongly dislike hard-coding things that aren't necessary.

> (You have some checks in your proposal but there are still
> situations where things can go wrong. Ugly things can happen if a tool
ends
> up in the wrong scope. It will load and work nicely but return wrong
> results because it operates on old data).

yep.  that's the way it goes.  if they do something wrong, then things
break.

> Implemenation-wise it's a minor
> change to what you propose. I'll write that code and then we can go from
> there.

ok.  i look forward to seeing it!

Nathan Bubna
nathan@esha.com


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [veltools] proposed change to ToolboxManager

[Gabriel Sidler <si...@teamup.ch>]

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
involves:

- 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
    instance.


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.


Gabe


--
Gabriel Sidler
Software Engineer, Eivycom GmbH, Zurich, Switzerland


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>