Hi Josef, On Fri, Nov 29, 2013 at 11:30 AM, jhaimerl <[email protected]> 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#HCommandManager . 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/xwiki-platform-gwt/xwiki-platform-gwt-user/src/main/java/org/xwiki/gwt/user/client/ui/rta/cmd/CommandManagerApi.java >> . >> >> Hope this helps, >> Marius >> >> On Mon, Sep 30, 2013 at 7:17 PM, Marius Dumitru Florea >> < > >> mariusdumitru.florea@ > >> > wrote: >>> On Mon, Sep 30, 2013 at 12:49 PM, jhaimerl < > >> Josef.Haimerl@ > >> > 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 < >>>> >>>>> 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-editor-tp7585599p7586853.html >>>>>> 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-editor-tp7585599p7587353.html >>>> 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-editor-tp7585599p7588168.html > Sent from the XWiki- Dev mailing list archive at Nabble.com. > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
