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 devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

Keep the annotations and thus the dependency.

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 devs(a)xwiki.org 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