> 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
