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

Yes, this was very helpfull http://extensions.xwiki.org/xwiki/bin/view/Extension/WYSIWYG+Editor+Module#… I make progress. Thanks! Marius Dumitru Florea wrote > &gt; wrote: >> Hi Marius, >> >> could you post a short example of making use of the CommandManagerApi. > > There's a short example here > http://extensions.xwiki.org/xwiki/bin/view/Extension/WYSIWYG+Editor+Module#… > . Is this clear enough? > > Hope this helps, > Marius > >> >> Thanks and regards >> >> Josef >> >> >> Marius Dumitru Florea wrote >>> Regarding the JavaScript plugin interface and the way to create >>> plugins in JavaScript, the JSX object on the plugin document could >>> contain something like this: >>> >>> ----------8<---------- >>> var wysiwygEditorPlugins = (function(plugins) { >>> // Define the plugin class. >>> var plugin = function() {}; >>> plugin.prototype.init = function(richTextArea, config) { >>> // >>> }; >>> plugin.prototype.getUIExtensions = function() { >>> // >>> } >>> plugin.prototype.destroy = function() { >>> // >>> }; >>> // Export the plugin class. >>> plugins['$escapetool.javascript($doc.name)'] = plugin; >>> return plugins; >>> })(wysiwygEditorPlugins || {}); >>> ---------->8---------- >>> >>> The JavaScript plugin factory (Java/GWT) will instantiate the plugin >>> like >>> this: >>> >>> var pluginInstance = new $wnd.wysiwygEditorPlugins[pluginName](); >>> >>> The JavaScript plugin (Java/GWT) will wrap the above plugin instance >>> (JavaScript object) and it will forward the Plugin interface >>> (Java/GWT) methods to the wrapped JavaScript object (native code), >>> adapting the parameters. The problem you have to overcome is the fact >>> that RichTextArea, Config or UIExtension are Java/GWT classes and thus >>> they cannot be reused in JavaScript as is so you have to make some >>> wrappers for them that expose the useful APIs to JavaScript code. Take >>> for instance >>> https://github.com/xwiki/xwiki-platform/blob/master/xwiki-platform-core/xwi… >>> . >>> >>> Hope this helps, >>> Marius >>> >>> On Mon, Sep 30, 2013 at 7:17 PM, Marius Dumitru Florea >>> &lt; >> >>> mariusdumitru.florea@ >> >>> &gt; wrote: >>>> On Mon, Sep 30, 2013 at 12:49 PM, jhaimerl &lt; >> >>>> >>> &gt; 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 &lt; >>>>> >>>>>>>>>> >>>>>> &gt; 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 >>>>>>> &lt;http://dev.xwiki.org/xwiki/bin/view/Design/WYSIWYGPluginInterface&gt; >>>>>>> . >>>>>>> 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 &lt; >>>>>>> >>>>>>>>>>>>>> >>>>>>>> &gt; 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 &lt; >>>>>>>>> >>>>>>>>>> rhierlmeier@ >>>>>>>>> >>>>>>>>>> &gt; 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 >>>>> >> >>>> >>>>>>> _______________________________________________ >>> 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.