From: Brian G. <br...@qu...> - 2003-07-25 03:22:55
|
Never thought I'd say it, but I think I agree with everything Lane says here :) Not 100% sure of the naming, but the concepts make perfect sense to me and should make everyone happy (if I understand their concerns.) >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. >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. >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. >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 -- Brian Goetz Quiotix Corporation br...@qu... Tel: 650-843-1300 Fax: 650-324-8032 http://www.quiotix.com |