New stuff:
I've found we need the notion of parent in the CM interface itself
(the reason is that when a CM implementation instantiates the
component, it could happen that the component has dependencies on
other components but located in parent CMs).
Thus in addition to what I've mentioned so far I'm also going to add a
get/setParent(ComponentManager) methods in the CM interface.
Again, please let me know if you have a pb with this.
Thanks
-Vincent
On Nov 26, 2009, at 12:20 PM, Vincent Massol wrote:
On Nov 26, 2009, at 12:10 PM, Thomas Mortagne wrote:
On Thu, Nov 26, 2009 at 12:02, Vincent Massol
<vincent(a)massol.net>
wrote:
On Nov 26, 2009, at 11:52 AM, Thomas Mortagne wrote:
On Thu, Nov 26, 2009 at 08:55, Vincent Massol
<vincent(a)massol.net>
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
>>>> <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
>> ______________________