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

[Lane S. <la...@op...>]

In digesting your note, I think we are in violent agreement with my 
initial proposal, no more and no less,  which accomodates 
configurability of automatic context loading, provides compatibility in 
2.0 with 1.x templates, and provides for pluggability of the auto 
context loader.

In raising the thread on Context aware methods (Keats proposal) and 
objects (your proposal),  I think this is different enough from Context 
Tools to merit a separate topic and discussion.

For now, unless Keats and ebr violently object, I think my proposal for 
context tools solves the contraints put forward.

I will be sure to have ContextTool extend ContextAware. Thanks.

-Lane

Marc Palmer wrote:

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

-- 
Lane Sharman
Learn About Conga, All Java GUI Builder: http://opendoors.com/conga