+1 with the Caty's idea. 2016-06-06 19:16 GMT+02:00 Vincent Massol <[email protected]>:
> > > On 06 Jun 2016, at 18:32, Marius Dumitru Florea < > [email protected]> wrote: > > > > On Mon, Jun 6, 2016 at 6:37 PM, Vincent Massol <[email protected]> > wrote: > > > >> > >>> On 06 Jun 2016, at 16:47, Marius Dumitru Florea < > >> [email protected]> wrote: > >>> > >>> On Sat, Jun 4, 2016 at 1:05 AM, Vincent Massol <[email protected]> > >> wrote: > >>> > >>>> 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) > >>>> > >>> > >>> 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 > an > >> admin option per wiki page! :) > >> > >> > > > >> When editing a page the user needs to be able to choose whether he wants > >> to edit with a visual editor or a syntax editor. > >> > > > > 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. > > Indeed, and that’s a recurrent problem we have. We need to offer the user > the option to switch to another editor too when editing xproperties. > > Thanks > -Vincent > > > * 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. > >>>> > >>> > >>> This translates into another configuration level: request. It means > being > >>> able to overwrite the preferred editors for a specific request. But > this > >> 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 > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > -- Guillaume Delhumeau ([email protected]) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
