Edit Modes vs. Editors

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Edit Modes vs. Editors

Marius Dumitru Florea
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
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Edit Modes vs. Editors

vmassol
Administrator
Hi Marius,

> On 03 Jun 2016, at 20:29, Marius Dumitru Florea <[hidden email]> 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)
* 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.

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
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Edit Modes vs. Editors

Denis Gervalle-2
Hi Marius,

I globally agree with your vision, which is definitely more in line with
the actual possibilities we have. However, if we follow it straight, we
gonna have one feature dropped that I am pretty sure many users will miss.
Currently, we have a special notion for contents, which is to edit it in
WYSIWYG mode or Text Mode.

This does not change your vision IMO, it just add one more concept, the
editor kind: some editors are plain text oriented (wiki, WebIDE, ...), and
others are WYSIWYG oriented (GWT, CK, ...).

My vision would be to keep that kind as significant about editors, so that
what you said so far about a single editors set would be true for two kind
of editors set. So that I can choose in my profile my default plain text
editor, my default WYSIWYG editor, and my default editor kind (the actual
setting we have already). And in the edit menu, the proposal from Vincent
could be reduced to providing a single direct link for your default kind of
editor so to the default editor you have for that kind, but if for example
you hold “shift” or “option/alt”, you would get the menu switched to the
other kind and therefore your other default editor. This method will not
work a touch/mobile device, but I doubt that it will be an issue.

Other alternative to the menu switch, the menu always goes to your
defaults, but you can switch between editor kinds from the editor page
without losing information. This looks like the “source” tab of the GWT
WYSIWYG, but using the true wiki editor in it and having the ability to
start with it without load the WYSIWYG (I have never really understand why
we had that hybrid source tab which compete with the wiki editor in the
mind of a basic user).

WDYT ?


On Sat, Jun 4, 2016 at 12:05 AM, Vincent Massol <[hidden email]> wrote:

> Hi Marius,
>
> > On 03 Jun 2016, at 20:29, Marius Dumitru Florea <
> [hidden email]> 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)
> * 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.
>
> 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
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
>



--
Denis Gervalle
SOFTEC sa - CEO
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Edit Modes vs. Editors

Aaron MacSween
In reply to this post by Marius Dumitru Florea
On 16-06-03 08:29 PM, Marius Dumitru Florea 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
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs

+1 to all of the above. Well thought out.
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Edit Modes vs. Editors

vmassol
Administrator
In reply to this post by Marius Dumitru Florea
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 <[hidden email]> 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
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Edit Modes vs. Editors

Aaron MacSween
My understanding is that Realtime GWT is not supported anymore.

If you have the realtime extensions installed (RTWYSIWYG or RTWIKI)
there's a small script that runs at page load and determines whether a
realtime session should begin. Currently this means sniffing the page a
bit to check what kind of editor is being used, and checking the user
has ticked the "disallow realtime" checkbox (which sets a flag in their
localstorage).

There was a little trial and error to figure out what we could test for
without getting false positives. Currently, realtime CKEditor checks the
URL, as we found that to be the most reliable indicator. A more official
API would be greatly appreciated, maybe something on the XWiki object?
I'm aware of the 'editor' field, but we haven't been able to use it
because $reasons.

Aaron


On 16-06-04 02:20 PM, Vincent Massol wrote:

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

_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Edit Modes vs. Editors

Thomas Mortagne
Administrator
In reply to this post by Denis Gervalle-2
+1 in general to the proposal with refinements from Vincent and Denis

Going a bit more into details I would like that we associated those
"Property Editors" extension points to xwiki-commons properties
descriptors which essentially means associate to Java Type (and
associated the existing xclass and xdocument fields to corresponding
properties, for example we could use XDOM as the Type for document
content and textarea allowing wiki content) so that we can start using
them easily for the growing number of properties based modules (wiki
macros parameters, filters parameters and in general anything that
want to expose extensions parameters should use that probably).

We will also need the corresponding extension system for "Property
Displayers" (view side) for consistency (I think it's cleaner to
separate edit and display and let an extension implement both if
wanted).


On Sat, Jun 4, 2016 at 10:48 AM, Denis Gervalle <[hidden email]> wrote:

> Hi Marius,
>
> I globally agree with your vision, which is definitely more in line with
> the actual possibilities we have. However, if we follow it straight, we
> gonna have one feature dropped that I am pretty sure many users will miss.
> Currently, we have a special notion for contents, which is to edit it in
> WYSIWYG mode or Text Mode.
>
> This does not change your vision IMO, it just add one more concept, the
> editor kind: some editors are plain text oriented (wiki, WebIDE, ...), and
> others are WYSIWYG oriented (GWT, CK, ...).
>
> My vision would be to keep that kind as significant about editors, so that
> what you said so far about a single editors set would be true for two kind
> of editors set. So that I can choose in my profile my default plain text
> editor, my default WYSIWYG editor, and my default editor kind (the actual
> setting we have already). And in the edit menu, the proposal from Vincent
> could be reduced to providing a single direct link for your default kind of
> editor so to the default editor you have for that kind, but if for example
> you hold “shift” or “option/alt”, you would get the menu switched to the
> other kind and therefore your other default editor. This method will not
> work a touch/mobile device, but I doubt that it will be an issue.
>
> Other alternative to the menu switch, the menu always goes to your
> defaults, but you can switch between editor kinds from the editor page
> without losing information. This looks like the “source” tab of the GWT
> WYSIWYG, but using the true wiki editor in it and having the ability to
> start with it without load the WYSIWYG (I have never really understand why
> we had that hybrid source tab which compete with the wiki editor in the
> mind of a basic user).
>
> WDYT ?
>
>
> On Sat, Jun 4, 2016 at 12:05 AM, Vincent Massol <[hidden email]> wrote:
>
>> Hi Marius,
>>
>> > On 03 Jun 2016, at 20:29, Marius Dumitru Florea <
>> [hidden email]> 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)
>> * 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.
>>
>> 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
>> [hidden email]
>> http://lists.xwiki.org/mailman/listinfo/devs
>>
>
>
>
> --
> Denis Gervalle
> SOFTEC sa - CEO
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs



--
Thomas Mortagne
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Edit Modes vs. Editors

Thomas Mortagne
Administrator
To give a very simple example:
* an extension provide a component with role
PropertyEditor<org.xwiki.contrib.mymodule.MyClass> and default hint

A little less simple example:
* each editor that propose to deal with date implement
PropertyEditor<java.util.Date> role with a unique hint
* a configurable "default" PropertyEditor<java.util.Date>
implementation is looking in your profile (then wiki configuration,
etc) to see which editor you want to use and call it (at the end
fallback on the first one found)

And here is how we could implement what Denis wants:
* a configurable "default"
PropertyEditor<org.xwiki.rendering.block.XDOM> editor which allow the
following
** choose the kind of editor you want
* a configurable "wysiwyg"
PropertyEditor<org.xwiki.rendering.block.XDOM> editor which allow the
following
** choose the exact WYSIWYG editor you want
* a configurable "text" PropertyEditor<org.xwiki.rendering.block.XDOM>
editor which allow the following
** choose the exact text editor you want
* have the following kind of structure for the hints of the actual
XDOM editors: <kind>|<uniquehint>. Here are some examples:
** wysiwyg|CKEditor
** wysiwyg|GWT
** text|plain
** text|highlighted
* it's easy to introduce any other kind of editor (voice ?)

On Mon, Jun 6, 2016 at 9:32 AM, Thomas Mortagne
<[hidden email]> wrote:

> +1 in general to the proposal with refinements from Vincent and Denis
>
> Going a bit more into details I would like that we associated those
> "Property Editors" extension points to xwiki-commons properties
> descriptors which essentially means associate to Java Type (and
> associated the existing xclass and xdocument fields to corresponding
> properties, for example we could use XDOM as the Type for document
> content and textarea allowing wiki content) so that we can start using
> them easily for the growing number of properties based modules (wiki
> macros parameters, filters parameters and in general anything that
> want to expose extensions parameters should use that probably).
>
> We will also need the corresponding extension system for "Property
> Displayers" (view side) for consistency (I think it's cleaner to
> separate edit and display and let an extension implement both if
> wanted).
>
>
> On Sat, Jun 4, 2016 at 10:48 AM, Denis Gervalle <[hidden email]> wrote:
>> Hi Marius,
>>
>> I globally agree with your vision, which is definitely more in line with
>> the actual possibilities we have. However, if we follow it straight, we
>> gonna have one feature dropped that I am pretty sure many users will miss.
>> Currently, we have a special notion for contents, which is to edit it in
>> WYSIWYG mode or Text Mode.
>>
>> This does not change your vision IMO, it just add one more concept, the
>> editor kind: some editors are plain text oriented (wiki, WebIDE, ...), and
>> others are WYSIWYG oriented (GWT, CK, ...).
>>
>> My vision would be to keep that kind as significant about editors, so that
>> what you said so far about a single editors set would be true for two kind
>> of editors set. So that I can choose in my profile my default plain text
>> editor, my default WYSIWYG editor, and my default editor kind (the actual
>> setting we have already). And in the edit menu, the proposal from Vincent
>> could be reduced to providing a single direct link for your default kind of
>> editor so to the default editor you have for that kind, but if for example
>> you hold “shift” or “option/alt”, you would get the menu switched to the
>> other kind and therefore your other default editor. This method will not
>> work a touch/mobile device, but I doubt that it will be an issue.
>>
>> Other alternative to the menu switch, the menu always goes to your
>> defaults, but you can switch between editor kinds from the editor page
>> without losing information. This looks like the “source” tab of the GWT
>> WYSIWYG, but using the true wiki editor in it and having the ability to
>> start with it without load the WYSIWYG (I have never really understand why
>> we had that hybrid source tab which compete with the wiki editor in the
>> mind of a basic user).
>>
>> WDYT ?
>>
>>
>> On Sat, Jun 4, 2016 at 12:05 AM, Vincent Massol <[hidden email]> wrote:
>>
>>> Hi Marius,
>>>
>>> > On 03 Jun 2016, at 20:29, Marius Dumitru Florea <
>>> [hidden email]> 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)
>>> * 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.
>>>
>>> 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
>>> [hidden email]
>>> http://lists.xwiki.org/mailman/listinfo/devs
>>>
>>
>>
>>
>> --
>> Denis Gervalle
>> SOFTEC sa - CEO
>> _______________________________________________
>> devs mailing list
>> [hidden email]
>> http://lists.xwiki.org/mailman/listinfo/devs
>
>
>
> --
> Thomas Mortagne



--
Thomas Mortagne
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Edit Modes vs. Editors

Ecaterina Moraru (Valica)
Hi,

I would make a distinction between these edit modes:
1. text/syntax/development modes and
2. user/visual modes.

1. is the "?editor=wiki" (we could rename it syntax/source/code). In the
future we could replace the current one with an editor that has syntax
highlight and other code enhancements. This mode would satisfy Vincent's
use case for development. The customization should be done from User
Profile / Administration. This will be available just for
Advanced/Technical users in the 'Edit' submenu.

2. is the "?editor=wysiwyg" (we could rename it visual/content). In this
category are all rich text editors intended for normal users: WYSIWYG,
CKEditor, Realtime, etc. This should be the default of edit mode. This
needs to have a separate configuration from the wiki mode (1).

So the Edit menu would be:
- "Edit" (default)
- "Inline"
- "Syntax"
- "Objects"
- "Class"

I don't believe listing all visual editors is scalable and desirable by
end-users. I believe the administration configuration is enough. But I
agree we need an edit mode dedicated for development.

So in User Profile, we would have:
- User type: Simple (User) | Advanced (Developer)
- Default Visual editor to use: WYSIWYG, CKEditor, etc. (with an extension
point)
- Default Syntax editor to use: Tiny MCE, Wiki (Default), etc.

So my idea is keeping the distinction of development / visual modes (with
better names) and having separate configurations for them.

Thanks,
Caty


On Mon, Jun 6, 2016 at 11:00 AM, Thomas Mortagne <[hidden email]>
wrote:

> To give a very simple example:
> * an extension provide a component with role
> PropertyEditor<org.xwiki.contrib.mymodule.MyClass> and default hint
>
> A little less simple example:
> * each editor that propose to deal with date implement
> PropertyEditor<java.util.Date> role with a unique hint
> * a configurable "default" PropertyEditor<java.util.Date>
> implementation is looking in your profile (then wiki configuration,
> etc) to see which editor you want to use and call it (at the end
> fallback on the first one found)
>
> And here is how we could implement what Denis wants:
> * a configurable "default"
> PropertyEditor<org.xwiki.rendering.block.XDOM> editor which allow the
> following
> ** choose the kind of editor you want
> * a configurable "wysiwyg"
> PropertyEditor<org.xwiki.rendering.block.XDOM> editor which allow the
> following
> ** choose the exact WYSIWYG editor you want
> * a configurable "text" PropertyEditor<org.xwiki.rendering.block.XDOM>
> editor which allow the following
> ** choose the exact text editor you want
> * have the following kind of structure for the hints of the actual
> XDOM editors: <kind>|<uniquehint>. Here are some examples:
> ** wysiwyg|CKEditor
> ** wysiwyg|GWT
> ** text|plain
> ** text|highlighted
> * it's easy to introduce any other kind of editor (voice ?)
>
> On Mon, Jun 6, 2016 at 9:32 AM, Thomas Mortagne
> <[hidden email]> wrote:
> > +1 in general to the proposal with refinements from Vincent and Denis
> >
> > Going a bit more into details I would like that we associated those
> > "Property Editors" extension points to xwiki-commons properties
> > descriptors which essentially means associate to Java Type (and
> > associated the existing xclass and xdocument fields to corresponding
> > properties, for example we could use XDOM as the Type for document
> > content and textarea allowing wiki content) so that we can start using
> > them easily for the growing number of properties based modules (wiki
> > macros parameters, filters parameters and in general anything that
> > want to expose extensions parameters should use that probably).
> >
> > We will also need the corresponding extension system for "Property
> > Displayers" (view side) for consistency (I think it's cleaner to
> > separate edit and display and let an extension implement both if
> > wanted).
> >
> >
> > On Sat, Jun 4, 2016 at 10:48 AM, Denis Gervalle <[hidden email]> wrote:
> >> Hi Marius,
> >>
> >> I globally agree with your vision, which is definitely more in line with
> >> the actual possibilities we have. However, if we follow it straight, we
> >> gonna have one feature dropped that I am pretty sure many users will
> miss.
> >> Currently, we have a special notion for contents, which is to edit it in
> >> WYSIWYG mode or Text Mode.
> >>
> >> This does not change your vision IMO, it just add one more concept, the
> >> editor kind: some editors are plain text oriented (wiki, WebIDE, ...),
> and
> >> others are WYSIWYG oriented (GWT, CK, ...).
> >>
> >> My vision would be to keep that kind as significant about editors, so
> that
> >> what you said so far about a single editors set would be true for two
> kind
> >> of editors set. So that I can choose in my profile my default plain text
> >> editor, my default WYSIWYG editor, and my default editor kind (the
> actual
> >> setting we have already). And in the edit menu, the proposal from
> Vincent
> >> could be reduced to providing a single direct link for your default
> kind of
> >> editor so to the default editor you have for that kind, but if for
> example
> >> you hold “shift” or “option/alt”, you would get the menu switched to the
> >> other kind and therefore your other default editor. This method will not
> >> work a touch/mobile device, but I doubt that it will be an issue.
> >>
> >> Other alternative to the menu switch, the menu always goes to your
> >> defaults, but you can switch between editor kinds from the editor page
> >> without losing information. This looks like the “source” tab of the GWT
> >> WYSIWYG, but using the true wiki editor in it and having the ability to
> >> start with it without load the WYSIWYG (I have never really understand
> why
> >> we had that hybrid source tab which compete with the wiki editor in the
> >> mind of a basic user).
> >>
> >> WDYT ?
> >>
> >>
> >> On Sat, Jun 4, 2016 at 12:05 AM, Vincent Massol <[hidden email]>
> wrote:
> >>
> >>> Hi Marius,
> >>>
> >>> > On 03 Jun 2016, at 20:29, Marius Dumitru Florea <
> >>> [hidden email]> 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)
> >>> * 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.
> >>>
> >>> 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
> >>> [hidden email]
> >>> http://lists.xwiki.org/mailman/listinfo/devs
> >>>
> >>
> >>
> >>
> >> --
> >> Denis Gervalle
> >> SOFTEC sa - CEO
> >> _______________________________________________
> >> devs mailing list
> >> [hidden email]
> >> http://lists.xwiki.org/mailman/listinfo/devs
> >
> >
> >
> > --
> > Thomas Mortagne
>
>
>
> --
> Thomas Mortagne
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
>
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Edit Modes vs. Editors

Marius Dumitru Florea
In reply to this post by vmassol
On Sat, Jun 4, 2016 at 1:05 AM, Vincent Massol <[hidden email]> wrote:

> Hi Marius,
>
> > On 03 Jun 2016, at 20:29, Marius Dumitru Florea <
> [hidden email]> 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?


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


>
> 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
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
>
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Edit Modes vs. Editors

vmassol
Administrator

> On 06 Jun 2016, at 16:47, Marius Dumitru Florea <[hidden email]> wrote:
>
> On Sat, Jun 4, 2016 at 1:05 AM, Vincent Massol <[hidden email]> wrote:
>
>> Hi Marius,
>>
>>> On 03 Jun 2016, at 20:29, Marius Dumitru Florea <
>> [hidden email]> 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
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Edit Modes vs. Editors

Marius Dumitru Florea
On Mon, Jun 6, 2016 at 6:37 PM, Vincent Massol <[hidden email]> wrote:

>
> > On 06 Jun 2016, at 16:47, Marius Dumitru Florea <
> [hidden email]> wrote:
> >
> > On Sat, Jun 4, 2016 at 1:05 AM, Vincent Massol <[hidden email]>
> wrote:
> >
> >> Hi Marius,
> >>
> >>> On 03 Jun 2016, at 20:29, Marius Dumitru Florea <
> >> [hidden email]> 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
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
>
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Edit Modes vs. Editors

vmassol
Administrator

> On 06 Jun 2016, at 18:32, Marius Dumitru Florea <[hidden email]> wrote:
>
> On Mon, Jun 6, 2016 at 6:37 PM, Vincent Massol <[hidden email]> wrote:
>
>>
>>> On 06 Jun 2016, at 16:47, Marius Dumitru Florea <
>> [hidden email]> wrote:
>>>
>>> On Sat, Jun 4, 2016 at 1:05 AM, Vincent Massol <[hidden email]>
>> wrote:
>>>
>>>> Hi Marius,
>>>>
>>>>> On 03 Jun 2016, at 20:29, Marius Dumitru Florea <
>>>> [hidden email]> 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
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Edit Modes vs. Editors

Guillaume Delhumeau
+1 with the Caty's idea.

2016-06-06 19:16 GMT+02:00 Vincent Massol <[hidden email]>:

>
> > On 06 Jun 2016, at 18:32, Marius Dumitru Florea <
> [hidden email]> wrote:
> >
> > On Mon, Jun 6, 2016 at 6:37 PM, Vincent Massol <[hidden email]>
> wrote:
> >
> >>
> >>> On 06 Jun 2016, at 16:47, Marius Dumitru Florea <
> >> [hidden email]> wrote:
> >>>
> >>> On Sat, Jun 4, 2016 at 1:05 AM, Vincent Massol <[hidden email]>
> >> wrote:
> >>>
> >>>> Hi Marius,
> >>>>
> >>>>> On 03 Jun 2016, at 20:29, Marius Dumitru Florea <
> >>>> [hidden email]> 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
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
>



--
Guillaume Delhumeau ([hidden email])
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Edit Modes vs. Editors

yaltis
In reply to this post by Marius Dumitru Florea
Hi,

I agree 100% with Vincent, there should be a quick way to switch between GWT and CKEditor. Have there been any evolutions on this topic ?

We've just migrated from XWiki 6.x to 8.4, and some users are not yet confortable with ckeditor, they are used to GWT. I had to configure GWT as default editor for them. An editor switcher would ease the transitition from GWT to CKEditor.

WDYT ?
Loading...