On Mon, Sep 30, 2013 at 12:49 PM, jhaimerl <[email protected]> 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
> [email protected]
> http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
[email protected]
http://lists.xwiki.org/mailman/listinfo/devs
