BTW we also need to take into account the 2 other use cases: * Realtime GWT WYSIWYG editor * Realtime CKEeditor editor
What I don’t know is how these are packaged. Are they full-fledged editors or just add-ons to editors that need to be turned on somehow? I guess the simplest is to consider them as full-fledged editors. Thanks -Vincent > 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. > > 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 > * 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? > > 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
