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

[Marc P. <ma...@an...>]

On Sat, 26 Jul 2003 17:55:07 -0400, Keats <ke...@su...> wrote:

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

No, I get all that! You've definitely misunderstood my posts.

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

This isn't a concern I have. Nothing in WM apart from templates can be 
dynamically deployed, so I don't think this is a major issue.

However, an abstracted factory for instantiating tools lets the application 
decide if it wants to support changes to the tools available at runtime.

I don't think it's something WM needs to worry about - let the application 
control it.

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

Well the idea is to abstract this to a single instance per Broker, of 
something like AutoContextLoader/LazyVariableFactory which is resposible 
for creating instances of any of the configured "lazy" tools (read 
ContextTools).

I believe this is what Lane and I have both proposed.

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

Hmm, interesting. It would enable apps to determine at template load time 
if any tools are not available, and hence not even try to render the 
template.

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

True. Still, we have pretty much decided we mustn't break anything in 2.0 
with CTs...

> 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?

Certainly interesting. I'm gonna hang back and watch because I'm tired of 
arguing about this stuff right now - and I seem to be at a tangent to most 
people on this :(

Marc
-- 
Marc Palmer
Contract Java Consultant/Developer
			
                        w a n g j a m m e r s

                 java and web software design
              experts with an ethical outlook

                   http://www.wangjammers.org