[xwiki-devs] [Proposal] Split the wysiwyg module in order to make the editor reusable outside XWiki
Hi devs, I'd like to split the wysiwyg module in two: xwiki-gwt-editor : All the client side except the editor initialization code. This module should depend only on xwiki-gwt-dom and xwiki-gwt-user. As a consequence, anyone should be able to inherit this module and reuse the editor outside XWiki. All the editor plugins are included but we don't enforce their use. This means that external parties can assemble whichever plugins they want and only those plugins will be compiled into JavaScript. Some plugins use services. External parties have to implement this services if they want to use the plugin. xwiki-gwt-editor-xwiki : XWiki-specific client initialization code plus all the server side (i.e. the XWiki implementation of plugin services). This module will depend on xwiki-gwt-editor and XWiki platform. All this is quite easy to do, except one thing. Plugin services are treated as components by XWiki which means service interfaces have to be annotated as component roles. This adds a dependency on xwiki-component-api to xwiki-gwt-editor. I see two options: (1) Keep the annotations and thus the dependency. This requires no effort but will make the editor less reusable for those who want to implement the services in a different way, using a different component manager for instance. (2) Remove the component role annotations and add some code to xwiki-gwt-editor-xwiki that dynamically registers as component roles at XWiki startup all the interfaces extending RemoteService (all GWT services must extend this interface). I'm not sure this is possible because components defined in components.txt are looked up earlier. Vincent, WDYT? We can improve later the organization and maybe split xwiki-gwt-editor in multiple modules, but for now this is the quickest way to make the editor reusable. I'm ready to do the split as soon as we agree on the details. WDYT? Thanks, Marius
On Sun, Jan 31, 2010 at 20:31, Marius Dumitru Florea <[email protected]> wrote:
Hi devs,
I'd like to split the wysiwyg module in two:
xwiki-gwt-editor : All the client side except the editor initialization code. This module should depend only on xwiki-gwt-dom and xwiki-gwt-user. As a consequence, anyone should be able to inherit this module and reuse the editor outside XWiki. All the editor plugins are included but we don't enforce their use. This means that external parties can assemble whichever plugins they want and only those plugins will be compiled into JavaScript. Some plugins use services. External parties have to implement this services if they want to use the plugin.
xwiki-gwt-editor-xwiki : XWiki-specific client initialization code plus all the server side (i.e. the XWiki implementation of plugin services). This module will depend on xwiki-gwt-editor and XWiki platform.
All this is quite easy to do, except one thing. Plugin services are treated as components by XWiki which means service interfaces have to be annotated as component roles. This adds a dependency on xwiki-component-api to xwiki-gwt-editor. I see two options:
(1) Keep the annotations and thus the dependency. This requires no effort but will make the editor less reusable for those who want to implement the services in a different way, using a different component manager for instance.
(2) Remove the component role annotations and add some code to xwiki-gwt-editor-xwiki that dynamically registers as component roles at XWiki startup all the interfaces extending RemoteService (all GWT services must extend this interface). I'm not sure this is possible because components defined in components.txt are looked up earlier. Vincent, WDYT?
We can improve later the organization and maybe split xwiki-gwt-editor in multiple modules, but for now this is the quickest way to make the editor reusable. I'm ready to do the split as soon as we agree on the details. WDYT?
Rendering is depending on xwiki component and is already seen as usable externally to XWiki (which mean component engine is too) so IMO you can keep the dependency on it. Don't you need some component engine for the WYSIWYG even outside of XWiki anyway (otherwise i don't see why you would have something depending on it) ?
Thanks, Marius _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
Thomas Mortagne wrote:
On Sun, Jan 31, 2010 at 20:31, Marius Dumitru Florea <[email protected]> wrote:
Hi devs,
I'd like to split the wysiwyg module in two:
xwiki-gwt-editor : All the client side except the editor initialization code. This module should depend only on xwiki-gwt-dom and xwiki-gwt-user. As a consequence, anyone should be able to inherit this module and reuse the editor outside XWiki. All the editor plugins are included but we don't enforce their use. This means that external parties can assemble whichever plugins they want and only those plugins will be compiled into JavaScript. Some plugins use services. External parties have to implement this services if they want to use the plugin.
xwiki-gwt-editor-xwiki : XWiki-specific client initialization code plus all the server side (i.e. the XWiki implementation of plugin services). This module will depend on xwiki-gwt-editor and XWiki platform.
All this is quite easy to do, except one thing. Plugin services are treated as components by XWiki which means service interfaces have to be annotated as component roles. This adds a dependency on xwiki-component-api to xwiki-gwt-editor. I see two options:
(1) Keep the annotations and thus the dependency. This requires no effort but will make the editor less reusable for those who want to implement the services in a different way, using a different component manager for instance.
(2) Remove the component role annotations and add some code to xwiki-gwt-editor-xwiki that dynamically registers as component roles at XWiki startup all the interfaces extending RemoteService (all GWT services must extend this interface). I'm not sure this is possible because components defined in components.txt are looked up earlier. Vincent, WDYT?
We can improve later the organization and maybe split xwiki-gwt-editor in multiple modules, but for now this is the quickest way to make the editor reusable. I'm ready to do the split as soon as we agree on the details. WDYT?
Rendering is depending on xwiki component and is already seen as usable externally to XWiki (which mean component engine is too) so IMO you can keep the dependency on it.
Don't you need some component engine for the WYSIWYG even outside of XWiki anyway (otherwise i don't see why you would have something depending on it) ?
No, you don't necessarily need a component engine. You can implement the GWT-RPC services using servlets like we did before moving to components. So I have some interfaces that can be implemented by a servlet or by a XWiki component. To be implemented by a XWiki component I had to add the component role annotations, which are useless if you choose to implement them with a servlet. Thanks, Marius
Thanks, Marius _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
I don't know anything about the "xwiki component" infrastructure, but as an external user I would prefer (2). Anyway, here are some thoughts if you choose (1):
Keep the annotations and thus the dependency.
If they are really only annotations then theoretically they would not cause problems. When something is marked with an annotation which is unknown at runtime, the JRE should ignore the unknown annotation. (There were some related bugs in the early JRE5 versions but I think they are all fixed now - eg. http://bugs.sun.com/view_bug.do?bug_id=6322301 .) If I'm right then the GWT compiler handles this as well, so unknown annotations are simply ignored during compilation. (A related - already fixed - issue is http://code.google.com/p/google-web-toolkit/issues/detail?id=1830 but I think there were many in the early GWT-1.5 days :). So the "xwiki component annotations" can be declared as a "provided" dependency, and a project can decide to include or not to include them as real compile/runtime dependency. (The m2eclipse plugin may have problems with this approach because it adds "provided" dependencies to the build path as well. But I think this would not affect end-users, only the developers of rta-editor. I will explain it further if you need.) Regards: Norbi 2010.01.31. 20:31 keltezéssel, Marius Dumitru Florea írta:
Hi devs,
I'd like to split the wysiwyg module in two:
xwiki-gwt-editor : All the client side except the editor initialization code. This module should depend only on xwiki-gwt-dom and xwiki-gwt-user. As a consequence, anyone should be able to inherit this module and reuse the editor outside XWiki. All the editor plugins are included but we don't enforce their use. This means that external parties can assemble whichever plugins they want and only those plugins will be compiled into JavaScript. Some plugins use services. External parties have to implement this services if they want to use the plugin.
xwiki-gwt-editor-xwiki : XWiki-specific client initialization code plus all the server side (i.e. the XWiki implementation of plugin services). This module will depend on xwiki-gwt-editor and XWiki platform.
All this is quite easy to do, except one thing. Plugin services are treated as components by XWiki which means service interfaces have to be annotated as component roles. This adds a dependency on xwiki-component-api to xwiki-gwt-editor. I see two options:
(1) Keep the annotations and thus the dependency. This requires no effort but will make the editor less reusable for those who want to implement the services in a different way, using a different component manager for instance.
(2) Remove the component role annotations and add some code to xwiki-gwt-editor-xwiki that dynamically registers as component roles at XWiki startup all the interfaces extending RemoteService (all GWT services must extend this interface). I'm not sure this is possible because components defined in components.txt are looked up earlier. Vincent, WDYT?
We can improve later the organization and maybe split xwiki-gwt-editor in multiple modules, but for now this is the quickest way to make the editor reusable. I'm ready to do the split as soon as we agree on the details. WDYT?
Thanks, Marius _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.733 / Virus Database: 271.1.1/2659 - Release Date: 01/31/10 07:39:00
Hi Norbert, Indeed, annotations should be harmless. We can start with option (1) having xwiki-component-api as a provided dependency until I find a way to register the component roles at runtime. Thanks, Marius Norbert Sándor wrote:
I don't know anything about the "xwiki component" infrastructure, but as an external user I would prefer (2).
Anyway, here are some thoughts if you choose (1):
Keep the annotations and thus the dependency.
If they are really only annotations then theoretically they would not cause problems. When something is marked with an annotation which is unknown at runtime, the JRE should ignore the unknown annotation. (There were some related bugs in the early JRE5 versions but I think they are all fixed now - eg. http://bugs.sun.com/view_bug.do?bug_id=6322301 .)
If I'm right then the GWT compiler handles this as well, so unknown annotations are simply ignored during compilation. (A related - already fixed - issue is http://code.google.com/p/google-web-toolkit/issues/detail?id=1830 but I think there were many in the early GWT-1.5 days :).
So the "xwiki component annotations" can be declared as a "provided" dependency, and a project can decide to include or not to include them as real compile/runtime dependency.
(The m2eclipse plugin may have problems with this approach because it adds "provided" dependencies to the build path as well. But I think this would not affect end-users, only the developers of rta-editor. I will explain it further if you need.)
Regards: Norbi
2010.01.31. 20:31 keltezéssel, Marius Dumitru Florea írta:
Hi devs,
I'd like to split the wysiwyg module in two:
xwiki-gwt-editor : All the client side except the editor initialization code. This module should depend only on xwiki-gwt-dom and xwiki-gwt-user. As a consequence, anyone should be able to inherit this module and reuse the editor outside XWiki. All the editor plugins are included but we don't enforce their use. This means that external parties can assemble whichever plugins they want and only those plugins will be compiled into JavaScript. Some plugins use services. External parties have to implement this services if they want to use the plugin.
xwiki-gwt-editor-xwiki : XWiki-specific client initialization code plus all the server side (i.e. the XWiki implementation of plugin services). This module will depend on xwiki-gwt-editor and XWiki platform.
All this is quite easy to do, except one thing. Plugin services are treated as components by XWiki which means service interfaces have to be annotated as component roles. This adds a dependency on xwiki-component-api to xwiki-gwt-editor. I see two options:
(1) Keep the annotations and thus the dependency. This requires no effort but will make the editor less reusable for those who want to implement the services in a different way, using a different component manager for instance.
(2) Remove the component role annotations and add some code to xwiki-gwt-editor-xwiki that dynamically registers as component roles at XWiki startup all the interfaces extending RemoteService (all GWT services must extend this interface). I'm not sure this is possible because components defined in components.txt are looked up earlier. Vincent, WDYT?
We can improve later the organization and maybe split xwiki-gwt-editor in multiple modules, but for now this is the quickest way to make the editor reusable. I'm ready to do the split as soon as we agree on the details. WDYT?
Thanks, Marius _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.733 / Virus Database: 271.1.1/2659 - Release Date: 01/31/10 07:39:00
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Tue, Feb 2, 2010 at 08:41, Marius Dumitru Florea <[email protected]> wrote:
Hi Norbert,
Indeed, annotations should be harmless. We can start with option (1) having xwiki-component-api as a provided dependency until I find a way to register the component roles at runtime.
You can find in many unit tests how to do it, actually even the init components are registered at runtime. See ComponenetManager#registerComponenent. Annotations and component manager are two different things: at startup XWiki components are loaded and given to ComponenetManager with a plain ComponentDescriptor generated from the annotations. But you still need to list them somewhere since you cant search for all classes implementing some interface in the classpath. (which is why we have component.txt files)
Thanks, Marius
Norbert Sándor wrote:
I don't know anything about the "xwiki component" infrastructure, but as an external user I would prefer (2).
Anyway, here are some thoughts if you choose (1):
Keep the annotations and thus the dependency.
If they are really only annotations then theoretically they would not cause problems. When something is marked with an annotation which is unknown at runtime, the JRE should ignore the unknown annotation. (There were some related bugs in the early JRE5 versions but I think they are all fixed now - eg. http://bugs.sun.com/view_bug.do?bug_id=6322301 .)
If I'm right then the GWT compiler handles this as well, so unknown annotations are simply ignored during compilation. (A related - already fixed - issue is http://code.google.com/p/google-web-toolkit/issues/detail?id=1830 but I think there were many in the early GWT-1.5 days :).
So the "xwiki component annotations" can be declared as a "provided" dependency, and a project can decide to include or not to include them as real compile/runtime dependency.
(The m2eclipse plugin may have problems with this approach because it adds "provided" dependencies to the build path as well. But I think this would not affect end-users, only the developers of rta-editor. I will explain it further if you need.)
Regards: Norbi
2010.01.31. 20:31 keltezéssel, Marius Dumitru Florea írta:
Hi devs,
I'd like to split the wysiwyg module in two:
xwiki-gwt-editor : All the client side except the editor initialization code. This module should depend only on xwiki-gwt-dom and xwiki-gwt-user. As a consequence, anyone should be able to inherit this module and reuse the editor outside XWiki. All the editor plugins are included but we don't enforce their use. This means that external parties can assemble whichever plugins they want and only those plugins will be compiled into JavaScript. Some plugins use services. External parties have to implement this services if they want to use the plugin.
xwiki-gwt-editor-xwiki : XWiki-specific client initialization code plus all the server side (i.e. the XWiki implementation of plugin services). This module will depend on xwiki-gwt-editor and XWiki platform.
All this is quite easy to do, except one thing. Plugin services are treated as components by XWiki which means service interfaces have to be annotated as component roles. This adds a dependency on xwiki-component-api to xwiki-gwt-editor. I see two options:
(1) Keep the annotations and thus the dependency. This requires no effort but will make the editor less reusable for those who want to implement the services in a different way, using a different component manager for instance.
(2) Remove the component role annotations and add some code to xwiki-gwt-editor-xwiki that dynamically registers as component roles at XWiki startup all the interfaces extending RemoteService (all GWT services must extend this interface). I'm not sure this is possible because components defined in components.txt are looked up earlier. Vincent, WDYT?
We can improve later the organization and maybe split xwiki-gwt-editor in multiple modules, but for now this is the quickest way to make the editor reusable. I'm ready to do the split as soon as we agree on the details. WDYT?
Thanks, Marius _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.733 / Virus Database: 271.1.1/2659 - Release Date: 01/31/10 07:39:00
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
On 01/31/2010 08:31 PM, Marius Dumitru Florea wrote:
Hi devs,
I'd like to split the wysiwyg module in two:
xwiki-gwt-editor : All the client side except the editor initialization code. This module should depend only on xwiki-gwt-dom and xwiki-gwt-user. As a consequence, anyone should be able to inherit this module and reuse the editor outside XWiki. All the editor plugins are included but we don't enforce their use. This means that external parties can assemble whichever plugins they want and only those plugins will be compiled into JavaScript. Some plugins use services. External parties have to implement this services if they want to use the plugin.
xwiki-gwt-editor-xwiki : XWiki-specific client initialization code plus all the server side (i.e. the XWiki implementation of plugin services). This module will depend on xwiki-gwt-editor and XWiki platform.
All this is quite easy to do, except one thing. Plugin services are treated as components by XWiki which means service interfaces have to be annotated as component roles. This adds a dependency on xwiki-component-api to xwiki-gwt-editor. I see two options:
(1) Keep the annotations and thus the dependency. This requires no effort but will make the editor less reusable for those who want to implement the services in a different way, using a different component manager for instance.
(2) Remove the component role annotations and add some code to xwiki-gwt-editor-xwiki that dynamically registers as component roles at XWiki startup all the interfaces extending RemoteService (all GWT services must extend this interface). I'm not sure this is possible because components defined in components.txt are looked up earlier. Vincent, WDYT?
We can improve later the organization and maybe split xwiki-gwt-editor in multiple modules, but for now this is the quickest way to make the editor reusable. I'm ready to do the split as soon as we agree on the details. WDYT?
+1. Splitting into small modules would be good, too, since it allows to choose which features will be available at runtime during the build process, so that the binaries aren't bloated with unwanted features. The downside is that the dependency list will be long. So, we could already go in this direction by putting all the current modules into a "bulk" submodule, and extract one by one the features into their own submodule. -- Sergiu Dumitriu http://purl.org/net/sergiu/
participants (4)
-
Marius Dumitru Florea -
Norbert Sándor -
Sergiu Dumitriu -
Thomas Mortagne