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

On 06 Jun 2016, at 18:32, Marius Dumitru Florea <

On Mon, Jun 6, 2016 at 6:37 PM, Vincent Massol &lt;vincent(a)massol.net&gt;

> >> On 06 Jun 2016, at 16:47, Marius Dumitru Florea < > mariusdumitru.florea(a)xwiki.com&gt; wrote: >> >> On Sat, Jun 4, 2016 at 1:05 AM, Vincent Massol &lt;vincent(a)massol.net&gt; > wrote: >> >>> 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

>>> the >>>> current WYSIWYG editor I came to the conclusion that we need to make

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

>>>> edit mode to edit the document title and content, another edit mode

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

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

>>> The >>>> editor obviously depends on the field type. There can be a date

>>>> (known as date picker), a plain text editor, a rich text editor, and

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

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

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

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

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

>>> this: >>> >> >> >>> * Some pages are good to be edited in WYSIWYG (pure content pages), > while >>> others are better edited using the wiki editor (code pages) >>> >> >> We should be able to configure the preferred editors for a given wiki > page >> like we do for user, wiki and farm. And we can with nested pages, by > using >> the "space" preferences. The code "space" of an application could be >> configured to use the plain text editor for instance. The question is > what >> is the fall-back chain? Can the user overwrite the preferred editor as > page >> or wiki level? > > That’s not what I meant. We’re not going to force users to have to set

You are referring to plain wiki pages here, but users interact a lot with structured pages also where they cannot choose from the edit menu the visual editor or the syntax editor.

* 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

>>> way to be able to very quickly select which editor to use without > having to >>> set it in your profile. >>> >> >> This translates into another configuration level: request. It means

>> able to overwrite the preferred editors for a specific request. But

> is >> generic and could be used for other configuration options, like the > hidden >> pages. > > Yes per request. But that’s technical. We need to find how it translates > in the UI. One option I mentioned is shortcut keys but that may not be > enough. Another idea is also what I suggested with the Edit menu showing > various options. > > Thanks > -Vincent > >> 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