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

Hi Marius, could you post a short example of making use of the CommandManagerApi.

Thanks and regards Josef Marius Dumitru Florea wrote > > wrote: >>> Hi Marius, >>> >>> I adopted your suggestions and updated the design proposal. Did you >>> already >>> think about the "interface"? >> >> Just two remarks for now: >> >> * The JSX object used for the plugin code should have "Use this >> extension" set to "On demand" as you load it on demand in macros.vm >> * I think each plugin should inject itself in wysiwygEditorPlugins >> (which should be an object not an array): >> >> // XWikiWysiwyg.js initializes the object. >> var wysiwygEditorPlugins = {}; >> >> // plugin JSX creates the plugin object and sets. >> wysiwygEditorPlugins['plugin-name-here'] = objectThatDefinesThePlugin; >> >> The rest looks good. I'll think of the plugin interface asap (this >> evening I hope). >> >> Thanks, >> Marius >> >>> >>> Thanks and regards, >>> >>> Josef >>> >>> >>> Marius Dumitru Florea wrote >>>> Hi Josef, >>>> >>>> On Fri, Aug 30, 2013 at 4:13 PM, jhaimerl < >>> >>>>>> >>>> > 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 >>>>> >>> >>>>>> >>>>>>>> _______________________________________________ >>>> 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