Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migration of unmigrated content due to installation of a new plugin

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:

Wiki Markup
\[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.

'_*

*HTML Form Editor_'

HTML One Form Editor

BXE/Bitflux Editor

Kupu/Epoz

Xopus

WebDAV/SVN

Download/Upload

 

Works with IE

YES

YES

NO ("Planned for the future")

YES

YES

Works with Mozilla

YES

YES

YES

YES

NO

Type of editor

Visual DOM tree

Plain

WYSIWYG

WYSIWYG

WYSIWYG

Can edit:

Any XML

Any unstructued text or XML

Any XML

XHTML only

Any XML

HTML/XHTML

YES (curently only supports subset of XHTML)

YES

YES (XHTML only)

YES

YES (XHTML only)

Works with Blog Publication

YES

YES

YES, technically certainly possible. Not sure about the actual state of the Schema/CSS/etc.. (Added by Christian Stocker)

NO

?

Other Issues/Features/Limitations

It is very timeconsuming to implement support for elements. Each xml element needs a seperate XSL template, and you have to basically recreate the schema in the xslt (for the drop down menus)

There is an open bug that makes editing very tedious. Basically each element has a ns (re)definition. (Michi is working on that: hiding the NS within a hidden field)

?

?

Original developers do not support Open Source version any longer

Comments by Andreas Kuckartz

Nice to have but not usable for practical purposes

Nice to have but not usable for practical purposes

?

?

A deadend

Comments by Dale Christ

Need to have to edit XML, unless there is a better option

Need to have to edit XML, unless there is a better option

BXE is currently severely broken at the moment, and should be considered unusable. You can to to the beginning of a required element, press the backspace key, and the contents of the current field and the prior field are merged. This may work for "text" fields, but this simply will not work for other required elements withon a blog entry (various times, author, etc). In fact it causes validation errors.(Commenty by Christian Stocker: The BXE integration for the Blog doctype was never really finished and is not done in the best way...) l

?

?

Comments by Michi

For simple doctypes (e.g. title, body) the perfect solution

good for administrators or copy paste

One person community and slow during startup

OSCOM

there is no alternative for IE than Xopus

Very good for large documents and non-browser based editors

in case no WebDAV client exists

Comments by thorsten

When the CForms editor is ready, it is perfect for blogs, news, forum, faq,...

It is nice for editing the source directly

interface*

interface*

interface*

openOffice docs, etc

assets yes

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:

No Format
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.