You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lenya.apache.org by Apache Wiki <wi...@apache.org> on 2005/03/28 21:18:49 UTC

[Lenya Wiki] Update of "Editors" by TorstenSchlabach

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Lenya Wiki" for change notification.

The following page has been changed by TorstenSchlabach:
http://wiki.apache.org/lenya/Editors

The comment on the change is:
Updated potential editors and general remarks / ideas on an editor plugin API

------------------------------------------------------------------------------
   * 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 1.4 and beyond. Beyond for XAML / XForms, 1.4 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.
  
@@ -21, +40 @@

  ||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||
  
+ == 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?
+ 
+ OpenSource / BSD style license
+ 
+ === 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
+