Date20-Sep-2005 11:57:33 EEST
JSPWiki version2.2.33
Idea CategoryProviderIdea
Idea StatusClosedIdea

Editor providers enable editor developers to embed their editors into JSPWiki with a simple interface.

The 2.3 version of JSPWiki will contain this editor provider in a quite more elegant way than i suggested in the discussion below. EditorProviders are now implemented as JSP Pages. You create a JSP Page for your editor, copy it into the /templates/default/editors directory and register it in the /WEB_INF/lib/ini/jspwiki_module.xml. Then you add the line jspwiki.editor=YourEditorName to the jspwiki.properties file and you are done.

Thanks Janne.

-- 23-March-2006 csauer

Old Discussion#

Factory Design Pattern#

It uses a factory class named EditorManager which would instanciate an EditorProvider of a certain type, indicated in the jspwiki.properties file by the jspwiki.editor property. For Example

An editor provider implements the EditorProvider interface which has the following three methods:

  • createIncludes() - Includes needed by the editors (JavaScript includes)
  • createEditorArea() - The area where to type in the text
  • createButtons() - The submit buttons

Here's an example code snipped which would be used in the doEndTag() method of the EditorAreaTag to create a generic editor area

    EditorManager em = new EditorManager(pageContext, getBodyContent() );
    EditorProvider provider = em.createProvider();
    pageContext.getOut().print( provider.createEditorArea().toString() );

New JSPTags needed#

In order to implement the EditorProvider interface two new tags are needed:

The EditorAreaTag and EditorTag will have to be modified to use the new EditorProvider Interface.

This class diagramm shows the usage of this interface with the currently available editors for JSPWiki. The plain editor is the standard text area based editor. FCKEditor and WikiWizard could overwrite certain methods. Both will overwrite the createTextArea() mehtod, while only WikiWizard for example will overwrite the createButtons() method to make them invisible by using a div tag with display:none style.


Installation with single ZIP file#

With all that in place it would be fairly simple to provide means of installation for a new Editor, say XEditor. Imagine the following szenario:

Developers of the editor could easily zip all necessary components for the xeditor into a single zip file and tell admins to do the following steps to install it.

  1. Unzip the xeditor.zip into the webapps dir of JSPWiki
  2. Set the jspwiki.editor property to the appropriate provider.
  3. Restart JSPWiki

Thats it.

A installation zipfile would look like this:

  • /scripts - contains the scripts (java scripts) for the editor
  • /WEB-INF/lib - contains xeditor.jar with the provider interface

I like this. I would do a couple of changes, though:

  1. Make the EditorManager a singleton, just like all other managers in JSPWiki, which turns the createEditor() method into createEditor( pageContext, getBodyContent() ).
  2. The editor must be switchable per user and also while editing. This probably needs thus an addition of the WikiContext somewhere.
  3. The EditorIncludesTag should be a generic tag type for all plugins, editors, javascript and what-have-you. See the discussion in BugAutomaticallyLoadPluginWithoutChangingSearchpathInJspwiki.properties. Combining these two effors would make a lot of sense.

-- JanneJalkanen

I'm still working on the inclusion of scripts/css parts of plugins.

Why not make an editor a plugin? And make it a special type of a plugin (For instance: It could implement WikiEditorIF or EditorProviferIF). If you make it known to jspwiki in the way I described on BugAutomaticallyLoadPluginWithoutChangingSearchpathInJspwiki.properties we can find out about ALL editors available. You can then make a dropdown box where the user (see point 2) can make a choice which editor to use. (Again here: see that there is no need to change the jspwiki.properties file? Just drop the plugin and it works)

Can you explain to me why you see a need for createButtons? Why not just include it in the createEditorArea?

-- KeesKuip

I think some people prefer the buttons above the editor box. Also, if you want to add custom fields to your submission, you need to put some other fields between the editor area and your submit buttons, otherwise it looks odd.

-- JanneJalkanen

The WikiWizard does not need the buttons at all. They are embedded in the toolbar and thus can be used with shortcuts. Actually the WikiWizard has to hide the buttons and issue the submit with a javascript function, in wich it sets the text into the invisible text area. If the buttons would be visible one could submit the form before the applet sets the text into the text area. By having the ability to overwrite the buttons (the wikiwizard sets them invisible) we can overcome this issue.

Here is the function WikiWizard is calling if CTRL+S is used in the applet (or the first button of the toolbar is pushed)

function SubmitText(txt)

-- ChristophSauer

Add new attachment

Only authorized users are allowed to upload new attachments.

List of attachments

Kind Attachment Name Size Version Date Modified Author Change note
editorproviders.png 13.0 kB 1 20-Sep-2005 11:59 ChristophSauer
« This page (revision-23) was last changed on 23-Aug-2006 17:48 by Candid Dauth