[xwiki-devs] [Proposal] Component isolation implementations
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
+1 On Tue, Sep 8, 2009 at 09:28, 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
+1 Vincent Massol 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
+1 - Asiri On Tue, Sep 8, 2009 at 12:58 PM, 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
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:
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
+0.5 for 2.0, i'm not sure since its a big change in a deep level but it does not sounds dangerous and not doing it in 2.0 will be a pain for merging On Mon, Sep 14, 2009 at 09:22, Vincent Massol <[email protected]> wrote:
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:
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
Hi, On Tue, Sep 15, 2009 at 11:36 AM, Thomas Mortagne <[email protected]
wrote:
+0.5 for 2.0, i'm not sure since its a big change in a deep level but it does not sounds dangerous and not doing it in 2.0 will be a pain for merging
On Mon, Sep 14, 2009 at 09:22, Vincent Massol <[email protected]> wrote:
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?
I'm +1 for 2.0 too since it's an important part of making wiki macros work well. Guillaume
Thanks -Vincent
On Sep 8, 2009, at 9:28 AM, Vincent Massol 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
-- Guillaume Lerouge Product Manager - XWiki Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/
On Mon, Sep 14, 2009 at 12:52 PM, Vincent Massol <[email protected]> wrote:
We need to decide if we want this only in 2.1M1 or also in 2.0 final or 2.0.x.
+1 for 2.0 - Asiri
On Sep 17, 2009, at 7:07 AM, Asiri Rathnayake wrote:
On Mon, Sep 14, 2009 at 12:52 PM, Vincent Massol <[email protected]> wrote:
We need to decide if we want this only in 2.1M1 or also in 2.0 final or 2.0.x.
+1 for 2.0
Note that since I had to move from this to working on skin stuff this issue is now postponed to at least 2.0.1. Thanks -Vincent
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) * 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(...). 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
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
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. 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
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. 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 <[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
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).
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
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
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
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
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 <[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
participants (5)
-
Asiri Rathnayake -
Guillaume Lerouge -
Jerome Velociter -
Thomas Mortagne -
Vincent Massol