Re: [Webmacro-devel] ContextTool replacement and thread-safety

[Keats <ke...@su...>]

There are so many points to respond to here it's a bit daunting but let 
me mention a couple things.

Marc, I think you have missed a crucial part of the ContextTool 
mechanism.  ContextTool *is* a lazy loading factory mechanism.  The 
init() method is not void; it returns an object.  Many tools just return 
themselves, but this is just a convenience.  A context tool provides 
arbitrary objects to the context, which may or may not have "context 
awareness".

I see three major shortcomings to the ContextTool mechanism:

1) Tools can only be configured through properties and can't be 
dynamically deployed.  This can be easily fixed using a the ConcurrentMap.

2) A ContextTool implementation (factory) class gets instantiated on 
each request in which it is referenced.  Although they are generally 
lightweight classes, this is still unnecessary overhead.  Factories 
should generally be static.  This should be easy to fix as well.

3) ContextTools are too magical, i.e, it's not clear to a 
developer/scripter what's available and how to use them.  This was a 
primary motivation for developing the #beam mechanism.

But the bean mechanism is flawed as well.  A #bean basically does two 
things that should be separate: Configuring an object and pulling the 
object into the context.   Most people seem to agree that configuring 
the object should not happen in the template.  On the other hand 
creating the reference to the object probably *should* happen in the 
template.  This makes it clear to the template developer that these 
things are there and will be used in the template.

So maybe the answer to problem 3) is to require tools to be declared in 
the template before they are used.  Maybe a directive like #tool, or 
#import, or #use.  E.g.,

#use $Math

or

#use "MathTool" as $Math

or something and then, $Math would get put into the context (assuming 
that MathTool had been deployed to the app previously somehow).

This would simplify the context logic: get() wouldn't need to know about 
tools at all.  And templates would become more readable.

On the downside, lot's of old templates would break and some people 
might be annoyed at having to declare commonly used tools in every 
template.  The latter problem could be mitigated by #including "header" 
templates that declare common tools (like $Request, $Response, $Session, 
$Form, etc.).

To deal with the backwards-compatability issue we could allow users to 
define "AutoLoadingTools" which get put into every context.  This would 
be less efficient than the current mechanism, but it wouldn't be too bad 
and it would ease the transition to the new paradigm.

What do y'all think?

Keats