On Nov 26, 2009, at 12:10 PM, Thomas Mortagne wrote: > On Thu, Nov 26, 2009 at 12:02, Vincent Massol <[email protected]> > wrote: >> >> On Nov 26, 2009, at 11:52 AM, Thomas Mortagne wrote: >> >>> 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. >> >> Why is it not true? It's what it does (yes I know that technically >> they are implemented as components implementing the ComponentManager >> role and thus don't bring any new tech concept, but in practice they >> do bring multi CM support to xwiki). > > Isn't ComponentManagerFactory part of the api ?
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 >>>> <[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
