Re: [xwiki-devs] Edit Modes vs. Editors

On 06 Jun 2016, at 16:47, Marius Dumitru Florea <

On Sat, Jun 4, 2016 at 1:05 AM, Vincent Massol &lt;vincent(a)massol.net&gt;

> Hi Marius, > >> On 03 Jun 2016, at 20:29, Marius Dumitru Florea < > mariusdumitru.florea(a)xwiki.com&gt; 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,

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

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

> is. >> >> An Editor is basically a form *field*. Most of the time it is an

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

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

>> (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

>> 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"

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

>> that will represent the Edit Mode for editing the document title,

>> and syntax. I'm not yet sure what name should we use for this Edit

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

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

> also have edit mode with editors. For example consider the following

> 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

> * Some pages are good to be edited in WYSIWYG (pure content pages),

We should be able to configure the preferred editors for a given wiki

like we do for user, wiki and farm. And we can with nested pages, by

the "space" preferences. The code "space" of an application could be configured to use the plain text editor for instance. The question is

is the fall-back chain? Can the user overwrite the preferred editor as

or wiki level?

* Right now we already have a similar issue with showing hidden pages. It > 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

This translates into another configuration level: request. It means being able to overwrite the preferred editors for a specific request. But this

generic and could be used for other configuration options, like the

pages.

I guess one solution could be to have shortcuts keys to force editing

> a given editor. I don’t know if it would be good enough though. > > WDYT? > > Thanks > -Vincent > >> Thanks, >> Marius