We have developed an EditorApplet for JSPWiki Markup. Please take a look at WikiWizard. We also would like to suggest an EditorProvider Interface for making it easier to embed different editors into JSPWiki


Very nice demo here of "the cross-browser rich-text editor [which] implements the Mozilla Rich Text Editing API included with Mozilla 1.3+". What's interesting:
  • submit button instead save icon in mozile
  • view source mode is as jspwiki current mode
  • maybe easier to port to jspwiki
Kupu seams to be too heavy for what we want, and should be harder to port.


Visualisation of WikiPages has improved a lot, but editing is still done in simple <textarea> fields. It's possible to have advanced editing capabilities in your browser by using some interesting JavaScripts.

I found two very interesting showcases how page editing could be improved a lot.

Please see for yourself:


Plone (http://plone.org) has a full WYSIWYG editor, called Epoz. Very impressive! Works on Mozila as well as IE.

-- YishayMor

There is a project that grew out of Epoz called Kupu. It has lots of great features and works with more servers. (Epoz is only Plone)

I'm impressed, but not sure how to make it work in JSPWiki-land. These client side editors use the browser to render the page. So it is a "simple" matter for them to edit the document and put the right HTML in and have the page render it.

Wiki markup is different from HTML. A conversion from Wiki markup to HTML would need to be done on the browser. This would mean that the code in TranslateReader would need to run on the browser. Maybe as a Java plugin?

-- FosterSchucker

I imagined doing something like this with a Java applet (!) to give the client-side wysiwyg editor, but loading/saving wiki markup via http. That way the server-side of the wiki remains completely unaware of what editor is in use. I imagine something quite simple -- no fancier markup than is already implemented -- just a "nicer" (for some category of users) interface.

-- MikeMorris

I think Javascript would be a good solution. Why don't we just use the very advanced existing JavaScript Solutions as they are? Kupu realy impressed me. As Foster wrote, the real problem is "how to make it work in JSPWiki-land". But this is possible. These Editors work with HTML - ok, JspWiki produces HTML. So we allready can edit a wiki page with these editors. What is left is the conversion back. We need a module that converts HTML back to JspWiki Markup Code. This is not a big task because we do not need to convert any HTML page back to JspWiki, we just need to convert the HTML produced by the Javascript Editor (and by Wiki itself). For the first step bold, italic, bullets, numbers, headlines and paragraphs should be enough, and tables would be the next step. -- SebastianBaltes

I worked on this yesterday and had good results. I was able to change the default editor to the rte editor and to save the changes back as wiki markup. It is not perfect right now, because there are a couple of special cases like links, plugins and filters, but for pure formated text it already works. -- SebastianBaltes

I have been thinking of making XHTML import functionality for quite some time now. It would be highly, highly useful. --JanneJalkanen

For this usecase (editing a wiki page with a wysiwyg html javascript editor) it could be helpful to use the wiki page as html, but without the plugin wiki markup translated to html (and maybe without the filters). The plugin markup syntax must be left untouched as it is because it is not possible to convert all plugins html output back to wiki markup. So my question: is there any option in the WikiEngine right now to disable the plugin processing? If not, this might be a neseccary change for the WikiEngine. -- SebastianBaltes

I think I can publish a Html2Wiki - Engine and a working wysiwyg html editor before 2005.2.20. It would be possible to choose between different javascript editors. But this includes a change to the JspWiki - Core, the edit.jsp and the edit-template.jsp. -- SebastianBaltes

If the changes are not too extensive, I'd love to include a WYSIWYG editor in the core. Could you either upload the relevant changes (in Diff format, see ContributingCode) here or email them to me? --JanneJalkanen

I email them in the next days. Currently I'm nearly ready with it, two simple bugfixes are left. The changes to the wiki core are just a few lines of codes. The new Html2Wiki-Translator is completely testet by JUnit. This module could also be used to translate most of hand written html to Jspwiki as you imagined, but I'm sure it will not work perfectly for any html because that's really a wide field. Especially for tables with colspans or things like that it would not work as expected, but for inter-wiki-import it could be something usefull ;-) -- SebastianBaltes

Hi, you should see this - http://gusanos.sourceforge.net/wp/. It turned up in a Google search. WYSIWYG is really needed. Plain Wiki is very limited in its usability, especially for expressing Tabular data.

Here's a list of some of the very popular WYSIWYG Editors:

Regards, Ashwin

This javascript based wiki to html is really great. This could be an alternative for direct html editing - but it would mean a lot of work to do. I'm going to run a test server this week (21-27.2.05) where you can try the pure html wysiwyg editing feature online. At the moment I'm using fckeditor and rte in my development environment and can switch between them and the plain editor online. There are still problems, e.g. using too many nested CSS or the need for an editor-integrated image upload, but I'm working on it -- SebastianBaltes

Hey, pretty nice! However, it seems to have problems with carriage returns - a complex document changes each time you change between the editors. But that is certainly very cool! Keep it up!

Now I've fresh energy ;-) - I will try to fix the bugs the next days and report here. -- SebastianBaltes

VERY cool!! I'm impressed. Some quirks still, but this shows a LOT of promise. -- MikeTaylor
INCREDIBLY AWESOME! When can we expect to see this in a jspwiki release? -- MikeBrown
Looks good! I liked the FCK Editor mode. There are some quirks though with Table creation and nested Bullets/Lists. Try creating a Table with Background colors for the Cells. It looks Ok in the Editor, but not in the Wiki. How did you manage to hook up Wiki with FCK Editor? By the way, I tried this with NS 7.1 not I.E ;-). I think you should write about it sometime - Ashwin
Note, on the Mac (Safari) you just get an HTML source text box, which isn't what you're supposed to see -- SteveS
This is a problem of the javascript Wysiwyg editors. As far as I understand they are only working in IE and firefox browsers. -- SebastianBaltes
I fixed some bugs and deployed a new version (2005-04-26). Please have a look again and make some tests: http://www.earthdawn-wiki.de/JSPWiki -- SebastianBaltes
The problem in the current JspWiki - CSS - implementation is that the syntax does not support nested tags and that it only supports block elements (div), so I added a new nestable syntax for span elements to the JspWiki core:
  %((style) text that will be formatted by 'style' %) 
  <span style="style"> text that will be formatted by 'style' </span>
You don't need to. Current CVS already has this code. It only outputs a div, if the percent-sequence is on its own line. See? It also nests (or should nest, if it does not, that's a bug). --JanneJalkanen
Having said that - if you can get this to work with current beta, I'll try and include it asap.
The nested CSS implementation of the current CVS seems to be still buggy as you can see at Test with nested CSS. I used some wiki markup code from the Wysiwyg-Test-Wiki and replaced the systax. It may be only a problem of the (rgb()). I fixed this in my own copy of the v2.1.144-alpha by adding a braket - counter. -- Sebastian
Hi Janne, I just mailed you the sources. -- Sebastian
My personal opinion, but I think it would be best to use plugins for the editor. Use SebastianBaltes idea of selecting the editor from the dropdown, and make the editor a plugin you can add. That way you get only the editors you want. -JoshM
HowToManuallyIntegrateFCKEditor -- Julien
How to integrate the TinyMCE WYSIWYG editor -- David Uctaa

Please Refactor Me

Doesn't the notion of a wysiwyg editor conflict with the idea of wiki pages?

Wikis are designed to expose formatting data to the user. Going wysiwyg would make it not wiki.

--AnonymousCoward, 18-May-2006

I don't know why you say that a wysiwyg editor conflicts with the idea of wiki pages. IMHO, if you have a wiki that is hard to edit, you have a useless wiki. Check out the definition of a wiki in wikipedia.org "A wiki is a type of website that allows users to easily add, remove, or otherwise edit and change some available content..." The key word here is "easily". If it isn't easy that that really gets around the point. I just installed jspwiki yesterday to play with for an internal wiki and was suprised to note that the FCK (or no other graphical editor) was part of the core install. This was disappointing to me. However, I am glad to note this page that mentions the FCK integration (I didn't look around enough for that) as well as other integrations.

--Jeff R., 28-Aug-2006

why add ajax to jspwiki? what's the main purpose of it in this project? * potentially for the rich text editor widget. --tangjianquan, 24-Jul-2006


--AnonymousCoward, 06-Sep-2006

How about this idea? IdeaSimpleHTMLMarkupLanguage

I think WYSIWYG function is very important! And when we change HTML 2 wiki markup, some information will lost!

--AnonymousCoward, 20-Sep-2006

Add new attachment

Only authorized users are allowed to upload new attachments.
« This page (revision-86) was last changed on 04-Apr-2010 08:34 by