There is a discussion going on about which editor(s) to support in Lenya.

Here are some issues which have been raised:

• We are too short on energy and developers to support this many editors.
• None of these editors currently support all of our needs.

To make the discussions easier to follow here is a table of the available editors showing their features and limitations.

Remarks by TorstenSchlabach:

[RT] Future of editor's in Lenya

Future here relates to 2.0 and beyond. Beyond for XAML / XForms, 2.0 for the rest IMO.

IMO it does not make sense to anyhow limit what editor's can be used with Lenya. We should keep the door open for any browser based editors, free or commercial, as well as for desktop editors or crossover incarnations we're likely going to see soon if XForms and XAML get's pace. I had also been thinking about hijacking any Java based pseudo desktop editor via Java Web Start. As a matter of fact people love what they are used to and each and every editor might have it's pro and cons; especially as long as we have this browser specific issues that overlay any decisions driven purely by functionality.

As it will be impossible to maintain a dozend or more editors and as it would be a wast of resources even if we had them, a good solution might be to have a clean editor plugin API in Lenya which will meet these requirements:

• Shares as much code / logic as possible, even between desktop and web based editors. Today all the code for RC and saving is duplicated among the usecases.
• Leaves the original editor distribution untouched (licensing) but provides a means for Lenya (or the plugin) to provide the necessary code for integration taking into account that it will probably take a lenya version / editor version matrix for the integration code. This is orthogonal to the current situation with Kupu for example, see http://issues.apache.org/bugzilla/show_bug.cgi?id=33794
• Provides a way to tell the Lenya core what documents can be edited and what it takes. An editor could for example state "I can edit any XML if you give me a RelaxNG schema, but I cannot read DTDs". Another editor might state "I am specialized in editing these particulat XML DOCTYPES in the sense of DTDs" and so on. Again another editor might state "I can edit XHTML with / without keeping non XHTML tags intact" (compare http://issues.apache.org/bugzilla/show_bug.cgi?id=33314).
• In any case Lenya resource types should be independent of editor plugins, but they need to communicate. An editor for example might need to be able to query all installed / enabled resource types and draw their DTD, RelaxNG or default ...2xhtml.xslts. The idea should still be: I take an editor plugin and a resource type plugin; the two never met before, but the editor can immediatelly edit instanced of the ressource type!
  

Please help fill in what you know, and add more rows for additional features, limitations, and any other concerns.

interface* - To make lenya plugable we need to define contracts for editors. That makes it possible that different editors can interact with this contracts. If a user wants a new editor in lenya (s)he has to provide the editor specific implementation of this contracts.

other editors to evaluate

If anyone has tried them, please share your findings here.

HTMLArea

http://www.dynarch.com/projects/htmlarea/

From that site:

Update, March 8 2005. Some time ago, InteractiveTools expressed the will to take over the project. We provided some fixes that we made and were not in the CVS version and a RC2 was released at htmlarea.com; however, soon thereafter InteractiveTools announced the project closed and forums discontinued. Bang! 

Our position on this is that the editor will keep going; we are actually making quite some progress in its development, but only in house at this time. We are still planning to release version 3.0, quite possibly under a different name (so it might actually be a 1.0) but still free, at least for the core editor--some plugins might be released under a commercial license. We can't provide explicit deadlines, so please bear with us. 

So if the site fades away, Google is your best friend.

Claims to be IE + Mozilla + "any Gecko Browser". This must be new as HTMLArea used to be IE only. Or at least it used to be that WYSIWYG is limited to IE while in Mozilla it will be just a text field.

Further licensing TBD to my understanding.

FCKEditor

http://www.fckeditor.net/

Claims to be IE and Mozilla (backward compatible IE 5.5+, Firefox 1.0+, Mozilla 1.3+ and Netscape 7+; remember browser adoption with the average user is slow!)

"Internet Explorer compatibility is available over Windows only." Does this mean: Yes, we support MacOS and IE, but not in this combination. Does anyone have any idea if this is for any technical reason?

FCKEditor is feature-rich, solid, clean, fast and well-designed, with a much more intuitive interface than Kupu. See HowToIntegrateFCKEditor.

License: LGPL

TinyMCE

http://tinymce.moxiecode.com/index.php

Again, IE + Mozilla, not tested on Mac yet, they're looking for one to be donated.

License: LGPL

Desktop Editors and Desktop CMS

jLibrary

http://jlibrary.javahispano.net/en/index.html

Based on Eclipse.

XFY

http://www.xfytec.com/whats/realize.html

xfy is a framework for authoring and editing compound XML documents in which multiple XML vocabularies can be integrated seamlessly in a uniform workspace.

Java application

XStandard

http://www.xstandard.com/

XStandard is a WYSIWYG XHTML Strict or 1.1 editor that can be embedded in applications on a Windows (and soon, MacOS X) computer, or embedded in a webpage. There is a Lite (free) and Pro (cost dependent on URLs and concurrent users) version. More information on the features and a download of the Lite version (30-day demo of Pro version also) is available at their website listed above. Rewritten from the ground-up to focus on web standards.