We need to decide if we want this only in 2.1M1 or also in 2.0 final or 2.0.x. Reminder: This is needed to allow wiki macros to be able to be written in multiwiki environments. Note: The code I have so far for it doesn't seem too dangerous. WDYT? Thanks -Vincent On Sep 8, 2009, at 9:28 AM, Vincent Massol wrote: _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

We need to decide if we want this only in 2.1M1 or also in 2.0 final or 2.0.x.

On Wed, Nov 25, 2009 at 3:06 PM, Vincent Massol <vincent(a)massol.net> wrote: Change of plan: I'm now no longer planning to modify what's below and thus it will stay as it is now: Thanks -Vincent

On Thu, Nov 26, 2009 at 08:55, Vincent Massol <vincent(a)massol.net> wrote: 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 > <vincent(a)massol.net> wrote: >> On Wed, Nov 25, 2009 at 3:06 PM, Vincent Massol >> <vincent(a)massol.net> 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 >>> <vincent(a)massol.net> 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

On Thu, Nov 26, 2009 at 12:02, Vincent Massol <vincent(a)massol.net> wrote: Isn't ComponentManagerFactory part of the api ?

>> What about xwiki-component-context >> (provide context based CMs) > > I don't think we can understand what it means by looking at it. > >> or xwiki-component-tools (a bunch of CM >> tools that are one abstraction level above CM module) ? > > I find tools too generic. This module is about multi CM. Tools make > it > sound optional when it's not optional. For example the Wiki Macro > Bridge won't work without these. > > I still think "-multi" is the best suggested so far with "-context" > being my second choice. I also hesitated with "-isolation" and "- > realm" initially. > > Thanks > -Vincent > >>> Thanks >>> -Vincent >>> >>> On Wed, Nov 25, 2009 at 3:56 PM, Vincent Massol >>> <vincent(a)massol.net> wrote: >>>> On Wed, Nov 25, 2009 at 3:06 PM, Vincent Massol >>>> <vincent(a)massol.net> 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 >>>>> <vincent(a)massol.net> 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 > ______________________

On Nov 26, 2009, at 12:10 PM, Thomas Mortagne wrote: Nope. I have moved it to "-multi" for that reason (in order to cleanly separate the multi concept). Thanks -Vincent >>> What about xwiki-component-context >>> (provide context based CMs) >> >> I don't think we can understand what it means by looking at it. >> >>> or xwiki-component-tools (a bunch of CM >>> tools that are one abstraction level above CM module) ? >> >> I find tools too generic. This module is about multi CM. Tools >> make it >> sound optional when it's not optional. For example the Wiki Macro >> Bridge won't work without these. >> >> I still think "-multi" is the best suggested so far with "-context" >> being my second choice. I also hesitated with "-isolation" and "- >> realm" initially. >> >> Thanks >> -Vincent >> >>>> Thanks >>>> -Vincent >>>> >>>> On Wed, Nov 25, 2009 at 3:56 PM, Vincent Massol >>>> <vincent(a)massol.net> wrote: >>>>> On Wed, Nov 25, 2009 at 3:06 PM, Vincent Massol >>>>> <vincent(a)massol.net> 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 >>>>>> <vincent(a)massol.net> 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 >> ______________________