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

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

Marc,

I don't really get this.  The way it works now is simple: 

when resolving a variable reference:

- check if the variable is in the context
- if yes, return the variable
- if not, check if it is a tool.
- if not, return undefined
- if yes, check if it has been initialized
- if no, initialize it
- else return the tool

(We'll there're also functions in there but you get the idea.)

We can probably improve on this a bit, but the basic mechanism is sound.  Why would you want to check each variable to see if it is "ContextAware"?  Why would we want to load every tool into every request when nothing is referencing it?  This is just extra overhead.  

If you want somethig to be context-aware, make it a tool or a Macro implementation (or a context-aware function if I can get people to agree on that concept).

Let's take things one step at a time.  First let's allow tools to be dynamically deployed and discovered using the new super duper thread-safe map.  I think everybody likes this idea.  Then we can hash out any optimizations or simplifications on how they are accessed from the context.

Cool?

Keats

-------Original Message-------
From: Marc Palmer <ma...@an...>
Sent: 07/25/03 06:43 PM
To: la...@op...
Subject: Re: [Webmacro-devel] ContextTool replacement and thread-safety

> 
> On Fri, 25 Jul 2003 09:16:20 -0700, Lane Sharman <la...@op...> 
wrote:


> Like I said in my initial proposal, this will not win over everyone on 
> all points but I think it is a workable solution allowing folks like you 

> to roll your own solution if that is what you desire If you implement 
> your own AutoProvider, then you you can look up your own ContextValues 
> from whatever :).
>
> If ContextTool is not a friendly interface name, then sure, I suppose we 

> could rename it ContextAware as you have suggested, refactor all the 
> implementations and tell everyone in 2.0 that the impl signature has 
> changed.
>
> Hopefully, Keats and ebr will sign off on this proposal and we will be 
> good to go.

My proposal (ContextTool is empty, extends ContextAware) means that no 
existing code is broken.

It also means we can add context-awareness to variables put into the 
context by the application (not the AutoContextProvider):

ctx.put( "x", myContextAwareImpl);

...would result in WM automatically calling init(context) on the variable 
if appropriate. However this is "magic" which some people, including 
myself, am not so sure about.

However we should have magic everywhere (vars AND tools from 
AutoContextProvider) -or-we have it nowhere - i.e. the code you quoted
that 
does instanceof ContextTool on the resulting tool obtained from 
AutoContextProvider should not be in Context at all, and the signature of 
AutoContextProvider's method should change to:


  Object getValue( String name, Context ctx)

..as I recommended many emails ago on this thread when I suggested the 
AutoContextProvider idea (AKA LazyVariableFactory).

So - magic everywhere, or nowhere?

If magic (calling tool.init(this)) is only available for tools obtained 
from AutoContextProvider, it seems totally wrong for Context to hold the 
logic that does this, when it does not do the same for normal variables.

Tools may not be context aware at all, depending on the impl of 
AutoContextProvider, and as such the instanceof would be completely 
redundant.

I think I am voting for "no magic at all". i.e. let AutoContextProvider 
call init on its tools, as it will know if they are compatible with 
ContextAware/ContextTool.

Marc