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

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

Marc,

We have a working interface: ContextTool.

One of the wins of my proposal is that if you do not like the current 
Context.get() mechanic:

            Object tool = _broker.getTool(name);
            if (tool != null)
            {
                try
                {
                    ContextTool ct = (ContextTool) tool;


you will have new altenate logic allowing you to have your own context 
provider

            AutoContextProvider autoProvider = _broker.getAutoProvider()
            if (autoProvider != null) {
                Object contextValue = autoProvider.getValue(name);
                 if (contextValue != null) {
                     if (contextValue instanceof ContextTool) 
((ContextTool)contextValue).init(this);
                     // and so on.


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.

-Lane


                 


 pluggable replacement architecture in which you can drop or not drop 
objects into the context. From this loader

Marc Palmer wrote:

> On Thu, 24 Jul 2003 20:20:47 -0700, Brian Goetz <br...@qu...> 
> wrote:
>
>>> 1) Governing principle 1: Existing WM apps which use a context tool 
>>> will not break in the new 2.0 distro. I think we owe that to our 
>>> user base. There are a lot of folks who use $Form, $Request, etc, 
>>> etc. out of the box.
>>
>>
>> +1 -- total agreement.
>
>
> +1 -- Even I uses $Response and $Form and a couple of others, but I 
> don't want people to be able to reconfig them!
>
>>> 2) Governing principle 2: New WM apps and architects can completely 
>>> suppress the Context Tool as magic through one directive in 
>>> WebMacro.properties: EnableContextToolLoading=false. In 
>>> WebMacro.defaults it is true by default.
>>
>>
>> +1 on concept; naming to be hashed out later.  We might want to 
>> support a list of magic thingie loaders, of which context tools will 
>> be one.  Something that loads default macros, functions, or 
>> directives might be another.
>
>
> -1 -- This is redundant IMO, given point (3)
>
>>> 3) Alternative context tool plug-in types can be plugged into the 
>>> context by a tool loader different than the default supplied in the 
>>> 2.0 distro. The default tool loader will be refactored to conform to 
>>> an interface, AutoContextLoader. Any "architect" can replace this 
>>> default tool loader with his own loader to add "magic" objects to 
>>> the context by implementing AutoContextLoader. Per the existing 
>>> logic,  on a ref to a null variable in Context.get(),  if 
>>> (EnableContextToolLoading==TRUE), the loader's interface will be 
>>> invoked with the reference to the broker to locate the supporting 
>>> object. AutoContextLoaderImpl: will be the property name.
>>
>>
>> +1 on concept; naming to be hashed out later.
>
>
> +1 only if AutoContextLoader = 
> o.w.tools.DefaultLegacyContextToolLoader in WM.defaults, so that if we 
> want to suppress auto-stuffing, we can just wipe this attribute in 
> WM.properties. This makes (2) redundant. Less code, less config, less 
> hassle :)
>
>>> 5) The Context Tool can be documented as a) a convenience with some 
>>> standard tools for the entry level WM app, b) easily disabled, or c) 
>>> pluggable by an architect seeking tight integration with default 
>>> tools as an elective feature of WebMacro.
>>
>>
>> +1
>
>
> +1 to the principle. I still think context-aware variables should be 
> part of this plan though - refactor ContextTool.init up to a 
> ContextAwareVariable interface... and do the instanceof...init(this) 
> thing when putting any var into the context. I think this is an 
> integral part because the smart way to do it is to modify the 
> contexttool interface in this way (push up the method to 
> ContextAwareVariable).
>
> Cheers


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