6 Jun
2016
6 Jun
'16
10 a.m.
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
<thomas.mortagne(a)xwiki.com> 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 <dgl(a)softec.lu> wrote:
--
Thomas Mortagne
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 <vincent(a)massol.net> wrote:
--
Thomas Mortagne Hi Marius,
--
Denis Gervalle
SOFTEC sa - CEO
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs On 03 Jun 2016, at 20:29, Marius Dumitru Florea
<
mariusdumitru.florea(a)xwiki.com> 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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs