Nathan, Geir,
based on your feedback I realized that my proposal from
yesterday regarding the ContextTool interface has some
deficiencies. There's actually more to it than you think
at first. I attempted to look at the problem a little more
systematically. My findings including a proposal on how
to proceed are below.
I am looking forward to your feedback.
Gabe
Design Goals
============
- Tools should be reusable in different frameworks.
- The handling of tools should be efficient:
- as few instances as needed
- efficient assembly of a Velocity context for a particular request
- Enable context tools to log
- A tool manager must be able to instantiate context tools
and setup the Velocity context automatically.
- Any object with public methods and a constructor without parameters
should be usable as a context tool.
Aspects of Context Tools
========================
I see the following three relevant aspects of a context tool from
the point of view of a tool manager:
1) Scope
--------
The scope of a context tool:
a) request
b) global [default]
Others? Like session scope?
2) Data Passed
--------------
The type of data passed to a context tool:
a) nothing [default]
b) Servlet request, servlet session, servlet context
Others?
3) Loggable
-----------
To log or not to log.
Implementation
==============
I propose the following implementation approach:
1) By default context tools receive the following treatment by tool
managers:
a) The tool is assumed to be of global scope, that is, one instance is
used for all requests during the entire runtime of the program.
b) The tool manager instantiates an object using a public constructor
with no parameters. No data is passed.
c) No logger is passed.
The default case applies if none of the interfaces defined below
are implemented. This allows any object with a public constructor
without parameters and public methods to be used as a context tool.
2) Every context tool class that needs non-default handling regarding
scope, data passed, or logging must implement an interface that
establishes a contract between context tool managers and a class of
context tools.
For context tools used in a servlet environment the following concrete
interface is proposed:
public interface ServletContextTool
{
// Define possible scopes
public static int REQUEST;
public static int GLOBAL;
// Methods
public static getInstance(ViewContext c);
public static getScope(int scope);
}
Interfaces for other environments can be defined as needed. Such
an interface essentially establishes a category of context tools.
3) Any context tool class that wishes to have access to a logger, must
implement the following interface. In environments where logging
is supported, the tool manager *may* use this interface to pass a
logger to the context tool. The context tool must be able to deal
with situations where no logger is passed.
public interface LogEnabled
{
public static void setLogger(Logger logger);
}
Logger is an interface that is to be defined.
4) Implementations of tool managers need to declare which categories
of context tools they support. Any tool category unknown to the tool
manager receives default treatments as defined under 1)
A few notes about the proposed implementation:
- I believe the above proposal establishes a flexible and extensible
framework for working with context tools. For the large category of
static, non-logging tools it does require any special measures.
For tools with special needs special handling is possible.
Above proposal is not fundamentally different from what we do today,
but it outlines it more formally.
- The above approach assumes that the scope of a context tool is
given by the design of the tool and is not something that needs to
be configurable by the user. I am looking forward to some feedback
from Nathan on this because he proposed yesterday to allow the
user to define scopes. I am wondering what examples of tools would
be where it makes sense to have the user choose the scope.
- The logging aspect is really orthogonal to the other two aspects.
Therefore, I defined an interface that deals just with this aspect
(based on best practices recommended by the Avalon framework).
--
Gabriel Sidler
Software Engineer, Eivycom GmbH, Zurich, Switzerland
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
