Re: [Webmacro-devel] ContexTool change info Wiki

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

On Sun, 27 Jul 2003 17:45:30 -0700, Brian Goetz <br...@qu...> wrote:

>> Please don't yell at me - as far as I can see I think this is what Lane 
>> and I are converging on, if nobody else.
>
> The direction is nice.  It has one quite serious flaw -- there can be
> only one auto-loader.  This seems like a crippling limitation, but
> fortunately there's a relatively easy fix.  See the proposal I put on
> that page.

Of course multiple handlers is nicer, although I was proposing to keep 
things as simple as possible to "get it past the board" :)   An aggregating 
handler would have solved the problem, if a little ugly.

> I estimate that I could implement this in a 100% backward compatible
> way in about an hour, with no additional performance overhead.  So its
> got to be pretty simple :)

The alternative solution is good. ThingieFactory is not defined in your 
example though - but I assume it just has init(Broker) and getVariable( 
String name, Context ctx).

However, I think to be in line with Context.get we might have to have it 
getVariable( Object key, Context ctx) - unless we have Context call 
key.toString() automatically.

Go for it, it has my vote.

Hurrah! I think we are finally there! Eric - what do you think of this 
solution though? I think the stuff you have raised vis a configuration 
template is very interesting, but a separate issue. We can clean up WM a 
bit with this solution, and then look at global init templates.

i.e. we could have a global template with:

#declare directive org.webmacro.directive.SomeDirective
#declare directive org.webmacro.directive.SomeOtherDirective
#declare function org.webmacro.functions.SomeClass.someFunc

...and so on. However if that template is reloadable (very nice...) we 
probably introduce a whole load of synchronisation we currently don't have 
to do.

I think really, an application that needs "reloadability" of config should 
just create a new Broker and throw away the old Broker and WM it was using - 
 much like webapp reloading in servlet containers. It seems the only safe / 
efficient way to do it.

That, however, requires us to abstract Settings a bit more I think, and 
introduce settings change listeners - or allow the application to provide 
its own Settings implementation to the Broker (I don't think we have this 
now) so that you don't even need to rely on Properties (which if passed 
programmatically cannot really be polled for changes), and all config can 
come from the app.

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