Re: [xwiki-devs] Adding a customer plugin to the wysiwyg editor

Hi Marius, I adopted your suggestions and updated the design proposal. Did you already think about the "interface"?

Thanks and regards, Josef Marius Dumitru Florea wrote > > wrote: >> Hi, >> >> @Vincent >> Thanks for the information! >> >> @Marius >> I put down a rough design for this here >> http://dev.xwiki.org/xwiki/bin/view/Design/WYSIWYGPluginInterface >> <http://dev.xwiki.org/xwiki/bin/view/Design/WYSIWYGPluginInterface> >> . >> It includes some code-snippets of a prototype I got working. There are >> some >> comments/inline comments - hope it's handleable. >> I didn't go to far with the design proposal, because I wanted to come >> clear >> with you first, that this is the right way. Also I wanted to discuss the >> "interface" for the JavaScript plugins. What do you think a plugin should >> can do? Please let me also know what you think about the naming of the >> classes, etc. > > I'm not sure the editor should be responsible for fetching the > JavaScript code of its custom plugins. I think I prefer the custom > plugins to be loaded outside of the editor (Java) code and thus the > editor just needs to be able to detect their presence. Something like: > > $xwiki.jsx.use('Space.SomeCustomPlugin') > $xwiki.jsfx.use('uicomponets/wysiwyg/anotherCustomPlugin.js') > ... > $xwiki.jsfx.use('js/xwiki/wysiwyg/xwe/XWikiWysiwyg.js', true) > > Of course, hard-coding the custom plugin includes is not an option and > your idea of defining the custom plugins in wiki pages is great. So > the above code could be written instead as: > > ## Load the custom plugins. > #foreach ($pluginName in $configuredListOfPlugins) > #set ($pluginDocumentReference = > $services.model.resolveDocument($pluginName)) > #if ($xwiki.exists($pluginDocumentReference)) > $xwiki.jsx.use($pluginDocumentReference) > #end > #end > ## Load the editor code. > $xwiki.jsfx.use('js/xwiki/wysiwyg/xwe/XWikiWysiwyg.js', true) > > Of course, the condition that checks if a plugin is a custom (wiki) > plugin can be refined, but you get the idea. Now, as for how a custom > plugin is defined, I think we should reuse the JSX mechanism. A plugin > document could have one or more JSX objects for holding the JavaScript > code of the plugin and one special object to mark the fact that the > document is a WYSIWYG editor plugin. I would use the document name as > the plugin name, the document title as the plugin pretty name and the > document content as the description. And since the JavaScript code > would be stored in a JSX object, the WysiwygPluginClass doesn't have > any property left, but we still need it as a marker. We can't have > empty classes so we could just add a placeholder property in the > WysiwygPluginClass for now. > > Next, the WYSIWYG editor needs to detect the available custom plugin > factories and initialize the plugins. The simplest solution is to use > a global variable, e.g. window.wysiwygEditorPlugins.foo where foo is > one of the plugin factories. JavaScriptPluginFactory#registerPlugins() > from your proposal would iterate over the properties of > window.wysiwygEditorPlugins and create a plugin factory that wraps the > JavaScript object (e.g. 'foo'). > > Finally you need to define the "interface" for the JavaScript plugins. > I'll come back on this in the following days. > > Hope this helps, > Marius > >> >> Thanks and regards, >> >> Josef >> >> >> vmassol wrote >>> Hi, >>> >>> Just FTR Marius is on holidays till the end of the week… ;) >>> >>> Thanks >>> -Vincent >>> >>> On Aug 23, 2013, at 1:24 PM, jhaimerl < >> >>>> >>> > wrote: >>> >>>> Hi Marius, >>>> >>>> I'm back on working on this. Maybe you can help me getting-in and tell >>>> me >>>> something about this mechanism (http://snag.gy/OVUoR.jpg). How are the >>>> plugins published at this point? >>>> >>>> I set up eclipse to debug the java code with the browser gwt dev >>>> plugin. >>>> Maybe it could be useful for someone, would you like that I document it >>>> somewhere? >>>> >>>> >>>> Marius Dumitru Florea wrote >>>>> Hi Richard, >>>>> >>>>> On Thu, Jun 6, 2013 at 9:02 AM, rhierlmeier < >>>> >>>>> rhierlmeier@ >>>> >>>>> > wrote: >>>>>> Hi, >>>>>> >>>>>> we studied the source code of the gwt wysiwyg editor but we found no >>>>>> official way to integrate an custom plugin. >>>>> >>>>> Yes, right now all the plugins are written in Java (GWT) and adding a >>>>> new plugin requires rebuilding the editor. We've been wanting to add >>>>> support for (dynamic) JavaScript plugins for some time but we didn't >>>>> because we focused on other things. >>>>> >>>>>> >>>>>> We have the impression that it should be relatively easy to establish >>>>>> a >>>>>> public API for registering customer plugins. >>>>>> >>>>>> The customer plugin would be delivered as javascript code with a >>>>>> global >>>>>> javascript function that implements PluginFactory interface. >>>>>> >>>>>> The WysiwygEditorConfigClass would have an addition property >>>>>> customerPlugins, containing a comma seperate list of strings of the >>>>>> PluginFactory method names. >>>>>> >>>>> >>>>>> Do you think that this is doable? >>>>> >>>>> Yes. I would write a generic JavaScriptPluginFactory (implementing >>>>> PluginFactory) and JavaScriptPlugin (implementing Plugin) to serve as >>>>> a bridge between GWT and plugins written in native JavaScript. >>>>> WysiwygEditorFactory would then iterate the list of JavaScript plugin >>>>> names and create a JavaScriptPluginFactory instance for each, passing >>>>> the name. The factory would simply create a new JavaScriptPlugin >>>>> instance, forwarding the name. The plugin would access the global >>>>> JavaScript variable with the given name and take from it the data >>>>> needed to implement the Plugin interface. Of course, you need to >>>>> define an "interface" for the JavaScript plugins, and they have to bee >>>>> able to add event listeners like a GWT plugin. >>>>> >>>>> A contribution on this topic would be more than welcomed. >>>>> >>>>> Thanks, >>>>> Marius >>>>> >>>>>> >>>>>> Regards >>>>>> >>>>>> Richard >>> >>> _______________________________________________ >>> devs mailing list >> >>>> >>>> >> >> >> >> >> -- >> View this message in context: >> http://xwiki.475771.n2.nabble.com/Adding-a-customer-plugin-to-the-wysiwyg-e… >> Sent from the XWiki- Dev mailing list archive at Nabble.com. >> _______________________________________________ >> devs mailing list >> -- View this message in context: http://xwiki.475771.n2.nabble.com/Adding-a-customer-plugin-to-the-wysiwyg-e… Sent from the XWiki- Dev mailing list archive at Nabble.com. _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs