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