Hi Marius,

> On 03 Jun 2016, at 20:29, Marius Dumitru Florea 
> <[email protected]> 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.

So far so good, I completely agree :)

> 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

And also falling back on the global preferences for the farm if not defined at 
the wiki level.

> * 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?

So I agree with everything you said. However it could also be possible to also 
have edit mode with editors. For example consider the following edit menu:

Edit
  |_ Content
    |_ … With Default Editor
    |_ … With GWT WYSIWYG
    |_ … With CKEditor
    |_ … With Wiki Editor
  |_ Inline / Form
…

So the Edit > Content menu entry could have sub menu entries to choose 
explicitly which editor to edit with for the fields which support a "content 
editor”.

There could be other options but I would definitely not like a solution where I 
have to go to my profile and change my preferences whenever I need to change 
the editor to edit a given page. There are several reasons for this:
* Some pages are good to be edited in WYSIWYG (pure content pages), while 
others are better edited using the wiki editor (code pages)
* Right now we already have a similar issue with showing hidden pages. It take 
a lot of time to switch back and forth and for devs it’s a pain.

So while I agree with everything you said, I’d like that we also find a way to 
be able to very quickly select which editor to use without having to set it in 
your profile.

I guess one solution could be to have shortcuts keys to force editing with a 
given editor. I don’t know if it would be good enough though.

WDYT?

Thanks
-Vincent

> Thanks,
> Marius
_______________________________________________
devs mailing list
[email protected]
http://lists.xwiki.org/mailman/listinfo/devs

Reply via email to