On Thu, Nov 26, 2009 at 12:20, Vincent Massol <[email protected]> wrote: > > 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).
Then yes xwiki-component-multi is the right name, i understood it was just supposed to contain a list of specific CMs. And where is the implementation of ComponentManagerFactory ? xwiki-component-default depends on xwiki-component-multi ? > > 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 > -- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
