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. > > > * 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 > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
