On Thu, Nov 26, 2009 at 08:55, Vincent Massol <[email protected]> wrote: > 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.
Well "xwiki-component-multi" looks like "the module adding the multi CM concept" which is not true. What about xwiki-component-context (provide context based CMs) or xwiki-component-tools (a bunch of CM tools that are one abstraction level above CM module) ? > > 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 > -- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
