The JavascriptBasedEditor is really neat and makes TWiki editing far more acceptable to users of current WYSIWYG applications. However I am still finding it difficult to get acceptance by typical users as they are so used to the instant gratification of full WYSIWYG, hence I was looking for a more WYSIWYG editor.

I think I have found one, Richtext Editor - Sourceforge - LGPL - details at http://www.bakedbeanandtomatosoup.co.uk/richtext/default.asp or code at https://sourceforge.net/projects/richtext/

The editor is Javascript but very much DHTML, so it will only work on a recent IE >5 browser. In my case this is not a problem as all the users will be on Windows. So it could be put in an iejs2 skin.

I would quite like to put it as an extra button on a simpler type of edit page so that people are encouraged to write simple pages, but if the page needs extra complexity then pushing the complex editor button it will bring up a popup window which will then edit the text.

If the editor was used in its current form it would generate HTML rather than Wiki markup language, so parsing for Wiki markup would need to be added and the buttons would need to generate Wiki, but display HTML to keep the WYSIWYG advantage.

This adaption is beyond my skills. Anybody interested? Any better ideas?

I could still use the editor without modification for our TWiki but would have a mixture of pages some largely HTML, rather against the simplisity of Wiki, but allowing some of the apparent of advantages of Quickplace / Notes / Manila-Frontier.

-- SimonGibbon - 13 Sep 2001

That certainly an interesting editor as it does appear to truely use DHTML rather than the hardwired IE HTML editor. I think the idea of offering it as an alternative to the TWiki syntax one is good for pure HTML editing. However, trying to add in TWiki syntax will be tough. What makes this sort of editor possible is having html rendering in the browser. Adding TWiki rendering would be pretty tough. You could think of holding TWiki syntax and HTML (e.g. when adding a link or setting something bold, but user editing could easily take the two out of synch). Another alternative might to add a bit extra to the html, so that it can be reversed into TWIki syntax at the server. Again it wouldn't be perfect as user editing could mess things up.

Oops just took a closed use - some use is made of document.execCommand. This looks like internal IE magic, that can't be altered, and hence only supports html. Also you need IE 5.5 +

-- JohnTalintyre - 14 Sep 2001

A pair of ideas to make the Javascript editor extendable (e.g. able to use syntax rules added by a plugin):

• each plugin could define some Javascript code needed to handle new syntax
• the code could be placed in the plugin main topic (as it is now with its one-line description)
• all fragments are collected in a %JSEDITORFRAGMENTS% variable that is replaced in the edit template

Second (and probably simpler way):

• put all special Javascript code for xxxPlugin syntax in a xxxPlugin.js file attached to xxxPlugin
• include such files in the edit header
• initialize all javascript loaded files to install UI and syntax rules

NEEDED: in both cases we need an API for defining such fragments.

The API could be informed about the Browser version so that it behaves the proper way

-- AndreaSterbini - 18 Sep 2001

Excellent idea. I think using attachment for js files is a good idea. Maybe plugin page should just give name of any scripts to include.

-- JohnTalintyre - 18 Sep 2001

I have a whole bunch of users who need true HTML editing in the browser. For them either IE's built in capability or this would work well.

-- MartinCleaver - 07 Nov 2001