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

jhaimerl Fri, 29 Nov 2013 01:31:04 -0800

Hi Marius,

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


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
> &lt;

> mariusdumitru.florea@

> &gt; wrote:
>> On Mon, Sep 30, 2013 at 12:49 PM, jhaimerl &lt;

> Josef.Haimerl@

> &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;
>>>
>>>> Josef.Haimerl@
>>>
>>>> &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;
>>>>>
>>>>>> Josef.Haimerl@
>>>>>
>>>>>> &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
>>>>>
>>>>>> 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

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

Reply via email to