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

On Mon, Sep 30, 2013 at 12:49 PM, jhaimerl <Josef.Haimerl(a)de-gmbh.com> wrote: 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 < > >> Josef.Haimerl@ > >> > 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 < >>> >>>> Josef.Haimerl@ >>> >>>> > 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 >>> >>>> devs@ >>> >>>> http://lists.xwiki.org/mailman/listinfo/devs >>> >>> >>> >>> >>> >>> -- >>> 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@ > >>> http://lists.xwiki.org/mailman/listinfo/devs >> _______________________________________________ >> devs mailing list > >> devs@ > >> http://lists.xwiki.org/mailman/listinfo/devs > > > > > > -- > 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