Hi Marius, I adopted your suggestions and updated the design proposal. Did you already think about the "interface"? 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@
-- View this message in context: http://xwiki.475771.n2.nabble.com/Adding-a-customer-plugin-to-the-wysiwyg-ed... Sent from the XWiki- Dev mailing list archive at Nabble.com. _______________________________________________ devs mailing list
devs@
devs mailing list
devs@
-- View this message in context: http://xwiki.475771.n2.nabble.com/Adding-a-customer-plugin-to-the-wysiwyg-ed... Sent from the XWiki- Dev mailing list archive at Nabble.com.