BTW we also need to take into account the 2 other use
cases:
* Realtime GWT WYSIWYG editor
* Realtime CKEeditor editor
What I don’t know is how these are packaged. Are they full-fledged editors or just
add-ons to editors that need to be turned on somehow?
I guess the simplest is to consider them as full-fledged editors.
Thanks
-Vincent
On 03 Jun 2016, at 20:29, Marius Dumitru Florea
<mariusdumitru.florea(a)xwiki.com> wrote:
Hi devs,
While working on adding extension points to support the replacement of the
current WYSIWYG editor I came to the conclusion that we need to make a
clear distinction between Edit Modes and Editors.
An Edit Mode is basically an HTML *form* that allows you to edit some data
that is associated with an XWiki document. There can be for instance an
edit mode to edit the document title and content, another edit mode to edit
the document objects, another one to edit the document access rights, and
so on. Ideally, XWiki extensions should be able to provide new edit modes.
The current place where we expose the Edit Modes is the Edit Menu. Class,
Objects, Access Rights, Inline Form are well defined edit modes. Before we
talk about the Wiki and WYSIWYG "edit modes" let's define what an editor
is.
An Editor is basically a form *field*. Most of the time it is an enhanced
form field, a widget, that allows you to edit a single document field. The
editor obviously depends on the field type. There can be a date editor
(known as date picker), a plain text editor, a rich text editor, and so on.
Ideally, XWiki extensions should be able to provide new editors for
specific data types. For instance an extension could replace the date
picker. Another one could replace the rich text editor.
The relation between Edit Modes and Editors is many to many. An Edit Mode
can use multiple editors and an Editor can be used by multiple Edit Modes.
For instance the rich text editor can be used in the "Content" edit mode
(for document content) but also in the Inline Form edit mode, for TextArea
object properties.
If we agree with this distinction then I think XWiki should have separate
extension points for Edit Modes vs. Editors.
What does this mean for the CKEditor integration? Well, CKEditor is an
editor.. so it doesn't make sense to have a "CKEditor" edit mode. CKEditor
can be used to edit the document content as well as the TextArea object
properties that contain wiki syntax. So there should be no "CKEditor" entry
in the Edit Menu. Otherwise we need to add "Inline Form - CKEditor" also,
and so on for each Edit Mode that can use the CKEditor.
So I think we should go in the following direction:
* Replace Wiki and WYSIWYG entries from the Edit menu with a single Entry
that will represent the Edit Mode for editing the document title, content
and syntax. I'm not yet sure what name should we use for this Edit Mode.
Let's call it "Content" for now.
* The default edit action (for simple users) will
** open the Inline Form edit mode if the document has a sheet associated
** open the "Content" edit mode otherwise
* The "Content" edit mode will use the Editor configured in the User
Profile, falling-back on the wiki preferences
* The Inline Form edit mode will use for TextArea properties the Editor
specified in the property meta data, falling-back on the User Profile
setting, then on the wiki preferences
* We should have an administration section to configure the default Editor
as wiki level (wiki preferences)
We don't have to implement all this right away. I'd like to start by making
the editor list from the TextArea meta data, User Profile and wiki
preferences extensible, so that CKEditor can add its entry there.
WDYT?
Thanks,
Marius
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org