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 ? > >> 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
