Hi Josef,
On Fri, Aug 30, 2013 at 4:13 PM, jhaimerl <Josef.Haimerl(a)de-gmbh.com> 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@
--
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