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 -- 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.

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. Thanks and regards, Josef vmassol wrote -- 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.

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 > &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 >> -- 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.

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(a)xwiki.com&gt; wrote:

Hi Josef, On Fri, Nov 29, 2013 at 11:30 AM, jhaimerl &lt;Josef.Haimerl(a)de-gmbh.com&gt; wrote: 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

Hi Marius, I made an update of the design proposal, where I adopted your suggestions. http://design.xwiki.org/xwiki/bin/view/Design/WYSIWYGPluginInterface <http://design.xwiki.org/xwiki/bin/view/Design/WYSIWYGPluginInterface> also I added a guide how to debug the wysiwyg-editor in eclipse with the gwt plugin here: http://extensions.xwiki.org/xwiki/bin/view/Extension/WYSIWYG+Editor+Module#… <http://extensions.xwiki.org/xwiki/bin/view/Extension/WYSIWYG+Editor+Module#HDebugging> Maybe you have a look at it and tell me, if its understandable and ok for you. For the JavaScript plugin interface, I tried exactly the same like already done with the CommandManagerApi for the textArea. Therewith I'm facing the problem that editor.getRichTextEditor().getTextArea() is not returning an java object like for the CommandManager, but the HTML DOM node of the the textArea. Hence (I believe of thinking) I'm not able to call the textArea's methods by its javascript object representative. I think I would rather need the functionality of the RichTextAreaImpl, but this also won't be right way. Can you help me out? You may have realized that I'm pretty new to all this stuff. Maybe we could take a concrete example for further explanations. What I would like to do, is to realize a plugin for the Wysiwyg-Editor, which saves a pasted image as attachement and adds an associated image macro to the textArea. I also think this would be a feature many users would love to have. Take as instance: http://xwiki.475771.n2.nabble.com/How-to-paste-image-in-the-WYSIWYG-editor-… Many thanks and regards Josef jhaimerl 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.