Addition: * I'll also create a xwiki-component-multi module to hold the multiCM implementations since otherwise if we have them in xwiki-component-default, it means xwiki-bridge will be required by all modules, including the rendering API module which is supposed to work without the bridge in standalone mode for example.
If you have a better name for that new module please suggest. Thanks -Vincent On Wed, Nov 25, 2009 at 3:56 PM, Vincent Massol <[email protected]> wrote: > On Wed, Nov 25, 2009 at 3:06 PM, Vincent Massol <[email protected]> wrote: >> Hi, >> >> I'm starting to work on this again. Compared to what was mentioned >> below here are the changes I'm bringing: >> >> * No need to modify the ComponentDescriptor to add a get/setAdditionalData >> * Addition of a new ComponentManagerFactory.createComponentManager() >> interface + EmbeddableComponentManagerFactory implementation >> * The Wiki/User/All CM are now independent of the underlying >> implementation (abstracted away by ComponentManagerFactory) > > Change of plan: I'm now no longer planning to modify what's below and > thus it will stay as it is now: > >> * Move EmbeddableComponentManager class to the internal package (ie >> make it non public) >> * Expose ComponentAnnotationLoader in the documentation >> >> The old way to initialize XWiki components: >> >> EmbeddableComponentManager ecm = new EmbeddableComponentManager(); >> ecm.initialize(classLoader); >> >> The new way: >> >> ComponentManagerFactory factory = new EmbeddableComponentManagerFactory(); >> ComponentAnnotationLoader() cal = new ComponentAnnotationLoader(); >> cal.initialize(factory.createComponentManager(), classLoader); >> >> This is cleaner since it spearates the creation of the CM from the >> loading of components. For ex it's possible to not load components >> from annotations and instead use CM.registerComponent(...). > > Thanks > -Vincent > >> Please shout quickly if there's something you don't like since I'm >> working on implementing this as you read it... :) >> >> Thanks >> -Vincent >> >> On Tue, Sep 8, 2009 at 8:28 AM, Vincent Massol <[email protected]> wrote: >>> Hi, >>> >>> We have the need to isolate groups of components. For ex a wiki macro >>> created in a subwiki should only be visible in that subwiki by default. >>> >>> Here's an implementation proposal that I'm planning to implement: >>> >>> * There's a Root Component Manager (the current CM) >>> * There are 3 components which implement the ComponentManager role and with >>> 3 hints: "wiki", "user" and "all". There's a CompositeComponentManager class >>> that allows chaining CM and the "all" CM chains the "default" (root CM), >>> "wiki" CM and "user" CM. This works the same as with the configuration >>> module. >>> * Other components can have CMs injected as they want (if not specified then >>> it's the default, etc). For ex: >>> >>> @Requirement("all") >>> private ComponentManager cm >>> >>> * Creation process. As for now the user creates the root CM and then the >>> annotation loader will create the descriptors for the other CMs and register >>> them against the root CM. They'll get instantiated once (singleton) the >>> first time they're looked up. >>> * In order to register a component for, say, a given "enterprise" wiki, we >>> need to add a new property to the ComponentDescriptor: >>> get/setAdditionalData(Object data). For example: wikiCM.registerComponent(CD >>> mycd) where cd.setAdditionalData("enterprise"). >>> * Last, Guice uses Modules to isolate component definitions so it should be >>> possible and relatively easy to port the implementation to Guice (even >>> though Guice uses static Modules we can make them dynamic). >>> >>> WDYT? >>> >>> Thanks >>> -Vincent >>> >>> >> > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
