Yes,

this was very helpfull
http://extensions.xwiki.org/xwiki/bin/view/Extension/WYSIWYG+Editor+Module#HAdjusttheeditorUIfromaJavaScriptExtension

I make progress.

Thanks!


Marius Dumitru Florea wrote
> Hi Josef,
> 
> On Fri, Nov 29, 2013 at 11:30 AM, jhaimerl <

> Josef.Haimerl@

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

> 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-tp7585599p7588171.html
Sent from the XWiki- Dev mailing list archive at Nabble.com.
_______________________________________________
devs mailing list
[email protected]
http://lists.xwiki.org/mailman/listinfo/devs

Reply via email to