Proposal for Macro inline edition

classic Classic list List threaded Threaded
35 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Proposal for Macro inline edition

Simon Urli
Hi everyone,

I'm working on the roadmap issues related to the inline edition with
WYSIWYG editor for macro content and macro parameters.

The first step is to add a flag to allow user specify that a content or
a parameter can be edited inline with the WYSIWYG editor.

The second step is to allow the CKEditor to detect where the content
and/or parameters should be edited.
Let's take the exampe of a simple macro without any parameter, which
currently produces this code:

<div class="box infomessage">
   <div class="title">
     <span class="icon info"></span>
     some title
   </div>
   Some content
</div>

We propose (me & Marius) to ask users to add a wrapper with a specific
class around the content to tell the editor it should only allow editing
this content, e.g.:

<div class="box infomessage">
   <div class="title">
     <span class="icon info"></span>
     some title
   </div>
   <span class="editable-content">Some content</span>
</div>

About parameters, our idea was to define a new metadata attribute and to
ask users to use it for specifying the content is editable, such as for
a parameter named foo:

<span class="editable-content" data-parameter="foo">my foo parameter
value</span>

However I don't know right now how the editor would manage cases such as:
<span class="editable-content">Some content with <span
class="editable-content" data-parameter="myparameter">a
parameter</span></span>

So:
   1. Do you agree on the usage of a class named "editable-content"
which would be used as a tag to allow inline edition?
   2. WDYT about using a data-parameter and this class for inline
editing of parameters?

Thanks,
Simon
--
Simon Urli
Software Engineer at XWiki SAS
[hidden email]
More about us at http://www.xwiki.com
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for Macro inline edition

vmassol
Administrator
Hi Simon,

> On 10 Sep 2018, at 13:05, Simon Urli <[hidden email]> wrote:
>
> Hi everyone,
>
> I'm working on the roadmap issues related to the inline edition with WYSIWYG editor for macro content and macro parameters.

Cool :) We've been waiting for a long time about this feature! See below.

> The first step is to add a flag to allow user specify that a content or a parameter can be edited inline with the WYSIWYG editor.
> The second step is to allow the CKEditor to detect where the content and/or parameters should be edited.
> Let's take the exampe of a simple macro without any parameter, which currently produces this code:
>
> <div class="box infomessage">
>  <div class="title">
>    <span class="icon info"></span>
>    some title
>  </div>
>  Some content
> </div>
>
> We propose (me & Marius) to ask users to add a wrapper with a specific class around the content to tell the editor it should only allow editing this content, e.g.:
>
> <div class="box infomessage">
>  <div class="title">
>    <span class="icon info"></span>
>    some title
>  </div>
>  <span class="editable-content">Some content</span>
> </div>

By “users”, I guess you mean macro developers?

So if I understand you well, you’re not planning to add a getter/setters to the Macro descriptor, to tell that the macro content contains wiki markup and that it should be editable in the WYSIWYG editor?

Is that because you want to be finer-grained and have macro content which can have parts editable with the WYSIWYG while having other parts of the content not editable (for example)?

Technically Macros don’t generate HTML, only XDOM. So in order to make it easier for java macro developers, I’d suggest to introduce some new wrapping Block to indicate this information. We might need something similar for wiki macros too, to make it more reusable and typed.

> About parameters, our idea was to define a new metadata attribute and to ask users to use it for specifying the content is editable, such as for a parameter named foo:
>
> <span class="editable-content" data-parameter="foo">my foo parameter value</span>

What’s your idea for editing parameters requiring WYSIWYG? How do you present them in the UI? Do you have any mockup?

> However I don't know right now how the editor would manage cases such as:
> <span class="editable-content">Some content with <span class="editable-content" data-parameter="myparameter">a parameter</span></span>
>
> So:
>  1. Do you agree on the usage of a class named "editable-content" which would be used as a tag to allow inline edition?

Small details, there’s already the “contenteditable” notion that exists (see https://developer.mozilla.org/fr/docs/Web/HTML/Attributs_universels/contenteditable) so “editable-content” is quite close. Maybe we should have something more xwiki-specific? or more WYSIWYG-specific? Like “editable-wysiwyg” or “wysiwyg-editable”.

My main comment is what I put above: how do we make it easy for macro developers to specify this information.

>  2. WDYT about using a data-parameter and this class for inline editing of parameters?

Before answering that part, I would need to understand what’s the proposal in term of UI.

Note that the main use case is for content but it’s nice if you can also support parameters. Now, accepting markup in parameters is not really a great use case IMO and is usually a design issue so I’m not sure we should spend that much time in supporting that. WDYT?

The only macro parameter I know ATM that supports markup is the “title” param of the {{box}} macro and I think it’s badly designed. Note: if you check the recent {{figure}} macro, I implemented this need by having a {{figureCaption}} nested macro.

BTW this raises a question, will you support WYSIWYG editing of nested macros?

Thanks
-Vincent

> Thanks,
> Simon

[snip]

Reply | Threaded
Open this post in threaded view
|

Re: Proposal for Macro inline edition

Simon Urli


On 9/10/18 1:35 PM, Vincent Massol wrote:

> Hi Simon,
>
>> On 10 Sep 2018, at 13:05, Simon Urli <[hidden email]> wrote:
>>
>> Hi everyone,
>>
>> I'm working on the roadmap issues related to the inline edition with WYSIWYG editor for macro content and macro parameters.
>
> Cool :) We've been waiting for a long time about this feature! See below.
>
>> The first step is to add a flag to allow user specify that a content or a parameter can be edited inline with the WYSIWYG editor.
>> The second step is to allow the CKEditor to detect where the content and/or parameters should be edited.
>> Let's take the exampe of a simple macro without any parameter, which currently produces this code:
>>
>> <div class="box infomessage">
>>   <div class="title">
>>     <span class="icon info"></span>
>>     some title
>>   </div>
>>   Some content
>> </div>
>>
>> We propose (me & Marius) to ask users to add a wrapper with a specific class around the content to tell the editor it should only allow editing this content, e.g.:
>>
>> <div class="box infomessage">
>>   <div class="title">
>>     <span class="icon info"></span>
>>     some title
>>   </div>
>>   <span class="editable-content">Some content</span>
>> </div>
>
> By “users”, I guess you mean macro developers?

Here yes it's the macro developer. I'll try to be more specific in my
answers.

>
> So if I understand you well, you’re not planning to add a getter/setters to the Macro descriptor, to tell that the macro content contains wiki markup and that it should be editable in the WYSIWYG editor?

Actually we're planning to add the getter/setter **and** the specific
markup for the editor. The getter/setter (which I called the flag
above), is here to specify that the macro will contain inline editable
content in WYSIWYG. The markup will specify *where* exactly is this
content, and what shouldn't be changed.

I guess that if the flag is set and the markup is not present, then the
entire content is considered as editable.

>
> Is that because you want to be finer-grained and have macro content which can have parts editable with the WYSIWYG while having other parts of the content not editable (for example)?

It's exactly why yes. On my example, the macro user won't be able to
change the content of the title.

>
> Technically Macros don’t generate HTML, only XDOM. So in order to make it easier for java macro developers, I’d suggest to introduce some new wrapping Block to indicate this information. We might need something similar for wiki macros too, to make it more reusable and typed.

I'd need to look more on wrapping block but after a quick overlook it
seems to make sense indeed.

>
>> About parameters, our idea was to define a new metadata attribute and to ask users to use it for specifying the content is editable, such as for a parameter named foo:
>>
>> <span class="editable-content" data-parameter="foo">my foo parameter value</span>
>
> What’s your idea for editing parameters requiring WYSIWYG? How do you present them in the UI? Do you have any mockup?

I don't have any mockup right now. FTM I see it like this:
  - when creating the macro, the current text input are improved with
the CKEditor for the editable content/parameters
  - when editing the macro, you stay in the main editor UI, but the
content is now editable instead of opening back the macro UI

>
>> However I don't know right now how the editor would manage cases such as:
>> <span class="editable-content">Some content with <span class="editable-content" data-parameter="myparameter">a parameter</span></span>
>>
>> So:
>>   1. Do you agree on the usage of a class named "editable-content" which would be used as a tag to allow inline edition?
>
> Small details, there’s already the “contenteditable” notion that exists (see https://developer.mozilla.org/fr/docs/Web/HTML/Attributs_universels/contenteditable) so “editable-content” is quite close. Maybe we should have something more xwiki-specific? or more WYSIWYG-specific? Like “editable-wysiwyg” or “wysiwyg-editable”.

I'm open to suggestion on this one. "wysiwyg-editable" could be nice.
>
> My main comment is what I put above: how do we make it easy for macro developers to specify this information.
>
>>   2. WDYT about using a data-parameter and this class for inline editing of parameters?
>
> Before answering that part, I would need to understand what’s the proposal in term of UI.
>
> Note that the main use case is for content but it’s nice if you can also support parameters. Now, accepting markup in parameters is not really a great use case IMO and is usually a design issue so I’m not sure we should spend that much time in supporting that. WDYT?

We just discuss about macro parameters with Ludovic and apparently they
cannot support line returns, so we might have to use a custom editor for
those.

>
> The only macro parameter I know ATM that supports markup is the “title” param of the {{box}} macro and I think it’s badly designed. Note: if you check the recent {{figure}} macro, I implemented this need by having a {{figureCaption}} nested macro.
>
> BTW this raises a question, will you support WYSIWYG editing of nested macros?

Not for the moment.

Simon
>
> Thanks
> -Vincent
>
>> Thanks,
>> Simon
>
> [snip]
>

--
Simon Urli
Software Engineer at XWiki SAS
[hidden email]
More about us at http://www.xwiki.com
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for Macro inline edition

Thomas Mortagne
Administrator
On Mon, Sep 10, 2018 at 2:13 PM Simon Urli <[hidden email]> wrote:

>
>
>
> On 9/10/18 1:35 PM, Vincent Massol wrote:
> > Hi Simon,
> >
> >> On 10 Sep 2018, at 13:05, Simon Urli <[hidden email]> wrote:
> >>
> >> Hi everyone,
> >>
> >> I'm working on the roadmap issues related to the inline edition with WYSIWYG editor for macro content and macro parameters.
> >
> > Cool :) We've been waiting for a long time about this feature! See below.
> >
> >> The first step is to add a flag to allow user specify that a content or a parameter can be edited inline with the WYSIWYG editor.
> >> The second step is to allow the CKEditor to detect where the content and/or parameters should be edited.
> >> Let's take the exampe of a simple macro without any parameter, which currently produces this code:
> >>
> >> <div class="box infomessage">
> >>   <div class="title">
> >>     <span class="icon info"></span>
> >>     some title
> >>   </div>
> >>   Some content
> >> </div>
> >>
> >> We propose (me & Marius) to ask users to add a wrapper with a specific class around the content to tell the editor it should only allow editing this content, e.g.:
> >>
> >> <div class="box infomessage">
> >>   <div class="title">
> >>     <span class="icon info"></span>
> >>     some title
> >>   </div>
> >>   <span class="editable-content">Some content</span>
> >> </div>
> >
> > By “users”, I guess you mean macro developers?
>
> Here yes it's the macro developer. I'll try to be more specific in my
> answers.
>
> >
> > So if I understand you well, you’re not planning to add a getter/setters to the Macro descriptor, to tell that the macro content contains wiki markup and that it should be editable in the WYSIWYG editor?
>
> Actually we're planning to add the getter/setter **and** the specific
> markup for the editor. The getter/setter (which I called the flag
> above), is here to specify that the macro will contain inline editable
> content in WYSIWYG. The markup will specify *where* exactly is this
> content, and what shouldn't be changed.

About that "flag", you seems to plan a boolean but I feel something
more generic that we want to introduce since a long time would be
better: make the content descriptor return a type like parameters
descriptors do. The kind of inline editing you have in mind right now
would then be associated to the type List<Block> for example (or
CompositeBlock or some another type if we want to differentiate
between wiki content modified by the macro and wiki content not
modified by the macro). The other types would be used in other use
cases (syntax coloring for scripts, json editor, etc.). The idea of
using Java type is to be consistent with parameters and reuse existing
the displayers in the macro modal window for example but it can cover
this need too.

>
> I guess that if the flag is set and the markup is not present, then the
> entire content is considered as editable.
>
> >
> > Is that because you want to be finer-grained and have macro content which can have parts editable with the WYSIWYG while having other parts of the content not editable (for example)?
>
> It's exactly why yes. On my example, the macro user won't be able to
> change the content of the title.
>
> >
> > Technically Macros don’t generate HTML, only XDOM. So in order to make it easier for java macro developers, I’d suggest to introduce some new wrapping Block to indicate this information. We might need something similar for wiki macros too, to make it more reusable and typed.
>
> I'd need to look more on wrapping block but after a quick overlook it
> seems to make sense indeed.
>
> >
> >> About parameters, our idea was to define a new metadata attribute and to ask users to use it for specifying the content is editable, such as for a parameter named foo:
> >>
> >> <span class="editable-content" data-parameter="foo">my foo parameter value</span>
> >
> > What’s your idea for editing parameters requiring WYSIWYG? How do you present them in the UI? Do you have any mockup?
>
> I don't have any mockup right now. FTM I see it like this:
>   - when creating the macro, the current text input are improved with
> the CKEditor for the editable content/parameters
>   - when editing the macro, you stay in the main editor UI, but the
> content is now editable instead of opening back the macro UI
>
> >
> >> However I don't know right now how the editor would manage cases such as:
> >> <span class="editable-content">Some content with <span class="editable-content" data-parameter="myparameter">a parameter</span></span>
> >>
> >> So:
> >>   1. Do you agree on the usage of a class named "editable-content" which would be used as a tag to allow inline edition?
> >
> > Small details, there’s already the “contenteditable” notion that exists (see https://developer.mozilla.org/fr/docs/Web/HTML/Attributs_universels/contenteditable) so “editable-content” is quite close. Maybe we should have something more xwiki-specific? or more WYSIWYG-specific? Like “editable-wysiwyg” or “wysiwyg-editable”.
>
> I'm open to suggestion on this one. "wysiwyg-editable" could be nice.
> >
> > My main comment is what I put above: how do we make it easy for macro developers to specify this information.
> >
> >>   2. WDYT about using a data-parameter and this class for inline editing of parameters?
> >
> > Before answering that part, I would need to understand what’s the proposal in term of UI.
> >
> > Note that the main use case is for content but it’s nice if you can also support parameters. Now, accepting markup in parameters is not really a great use case IMO and is usually a design issue so I’m not sure we should spend that much time in supporting that. WDYT?
>
> We just discuss about macro parameters with Ludovic and apparently they
> cannot support line returns, so we might have to use a custom editor for
> those.
>
> >
> > The only macro parameter I know ATM that supports markup is the “title” param of the {{box}} macro and I think it’s badly designed. Note: if you check the recent {{figure}} macro, I implemented this need by having a {{figureCaption}} nested macro.
> >
> > BTW this raises a question, will you support WYSIWYG editing of nested macros?
>
> Not for the moment.
>
> Simon
> >
> > Thanks
> > -Vincent
> >
> >> Thanks,
> >> Simon
> >
> > [snip]
> >
>
> --
> Simon Urli
> Software Engineer at XWiki SAS
> [hidden email]
> More about us at http://www.xwiki.com



--
Thomas Mortagne
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for Macro inline edition

Marius Dumitru Florea
In reply to this post by vmassol
On Mon, Sep 10, 2018 at 2:35 PM, Vincent Massol <[hidden email]> wrote:

> Hi Simon,
>
> > On 10 Sep 2018, at 13:05, Simon Urli <[hidden email]> wrote:
> >
> > Hi everyone,
> >
> > I'm working on the roadmap issues related to the inline edition with
> WYSIWYG editor for macro content and macro parameters.
>
> Cool :) We've been waiting for a long time about this feature! See below.
>
> > The first step is to add a flag to allow user specify that a content or
> a parameter can be edited inline with the WYSIWYG editor.
> > The second step is to allow the CKEditor to detect where the content
> and/or parameters should be edited.
> > Let's take the exampe of a simple macro without any parameter, which
> currently produces this code:
> >
> > <div class="box infomessage">
> >  <div class="title">
> >    <span class="icon info"></span>
> >    some title
> >  </div>
> >  Some content
> > </div>
> >
> > We propose (me & Marius) to ask users to add a wrapper with a specific
> class around the content to tell the editor it should only allow editing
> this content, e.g.:
> >
> > <div class="box infomessage">
> >  <div class="title">
> >    <span class="icon info"></span>
> >    some title
> >  </div>
> >  <span class="editable-content">Some content</span>
> > </div>
>
> By “users”, I guess you mean macro developers?
>
> So if I understand you well, you’re not planning to add a getter/setters
> to the Macro descriptor, to tell that the macro content contains wiki
> markup and that it should be editable in the WYSIWYG editor?
>
> Is that because you want to be finer-grained and have macro content which
> can have parts editable with the WYSIWYG while having other parts of the
> content not editable (for example)?
>
>

> Technically Macros don’t generate HTML, only XDOM. So in order to make it
> easier for java macro developers, I’d suggest to introduce some new
> wrapping Block to indicate this information. We might need something
> similar for wiki macros too, to make it more reusable and typed.
>

+1. We should avoid duplicating the markup that makes the content editable
in every macro that allows it.


>
> > About parameters, our idea was to define a new metadata attribute and to
> ask users to use it for specifying the content is editable, such as for a
> parameter named foo:
> >
> > <span class="editable-content" data-parameter="foo">my foo parameter
> value</span>
>
> What’s your idea for editing parameters requiring WYSIWYG? How do you
> present them in the UI? Do you have any mockup?
>
> > However I don't know right now how the editor would manage cases such as:
> > <span class="editable-content">Some content with <span
> class="editable-content" data-parameter="myparameter">a
> parameter</span></span>
> >
> > So:
> >  1. Do you agree on the usage of a class named "editable-content" which
> would be used as a tag to allow inline edition?
>
> Small details, there’s already the “contenteditable” notion that exists
> (see https://developer.mozilla.org/fr/docs/Web/HTML/Attributs_
> universels/contenteditable) so “editable-content” is quite close. Maybe
> we should have something more xwiki-specific? or more WYSIWYG-specific?
> Like “editable-wysiwyg” or “wysiwyg-editable”.
>

We should probably also prefix it with "macro" or "wikimacro". So something
like "wikimacro-wysiwyg-editable" (although I think we can find a better
naming).


>
> My main comment is what I put above: how do we make it easy for macro
> developers to specify this information.
>
> >  2. WDYT about using a data-parameter and this class for inline editing
> of parameters?
>
> Before answering that part, I would need to understand what’s the proposal
> in term of UI.
>
>

> Note that the main use case is for content but it’s nice if you can also
> support parameters. Now, accepting markup in parameters is not really a
> great use case IMO and is usually a design issue so I’m not sure we should
> spend that much time in supporting that. WDYT?
>

Even if it's plain text it would still be nice to allow the user to edit
the parameter inline if the parameter appears as is in the macro output. Of
course, this won't apply to all macro parameters, but even if it's just one
parameter, it would still be useful.


>
> The only macro parameter I know ATM that supports markup is the “title”
> param of the {{box}} macro and I think it’s badly designed. Note: if you
> check the recent {{figure}} macro, I implemented this need by having a
> {{figureCaption}} nested macro.
>

That's OK when the macro parameter is optional and the position in the
macro output is not fixed. But if you want the title to be mandatory or if
you want the title to always be displayed before the message then you can't
allow the user to edit freely the macro content.


>
> BTW this raises a question, will you support WYSIWYG editing of nested
> macros?
>
> Thanks
> -Vincent
>
> > Thanks,
> > Simon
>
> [snip]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for Macro inline edition

Marius Dumitru Florea
In reply to this post by Thomas Mortagne
On Mon, Sep 10, 2018 at 3:42 PM, Thomas Mortagne <[hidden email]>
wrote:

> On Mon, Sep 10, 2018 at 2:13 PM Simon Urli <[hidden email]> wrote:
> >
> >
> >
> > On 9/10/18 1:35 PM, Vincent Massol wrote:
> > > Hi Simon,
> > >
> > >> On 10 Sep 2018, at 13:05, Simon Urli <[hidden email]> wrote:
> > >>
> > >> Hi everyone,
> > >>
> > >> I'm working on the roadmap issues related to the inline edition with
> WYSIWYG editor for macro content and macro parameters.
> > >
> > > Cool :) We've been waiting for a long time about this feature! See
> below.
> > >
> > >> The first step is to add a flag to allow user specify that a content
> or a parameter can be edited inline with the WYSIWYG editor.
> > >> The second step is to allow the CKEditor to detect where the content
> and/or parameters should be edited.
> > >> Let's take the exampe of a simple macro without any parameter, which
> currently produces this code:
> > >>
> > >> <div class="box infomessage">
> > >>   <div class="title">
> > >>     <span class="icon info"></span>
> > >>     some title
> > >>   </div>
> > >>   Some content
> > >> </div>
> > >>
> > >> We propose (me & Marius) to ask users to add a wrapper with a
> specific class around the content to tell the editor it should only allow
> editing this content, e.g.:
> > >>
> > >> <div class="box infomessage">
> > >>   <div class="title">
> > >>     <span class="icon info"></span>
> > >>     some title
> > >>   </div>
> > >>   <span class="editable-content">Some content</span>
> > >> </div>
> > >
> > > By “users”, I guess you mean macro developers?
> >
> > Here yes it's the macro developer. I'll try to be more specific in my
> > answers.
> >
> > >
> > > So if I understand you well, you’re not planning to add a
> getter/setters to the Macro descriptor, to tell that the macro content
> contains wiki markup and that it should be editable in the WYSIWYG editor?
> >
> > Actually we're planning to add the getter/setter **and** the specific
> > markup for the editor. The getter/setter (which I called the flag
> > above), is here to specify that the macro will contain inline editable
> > content in WYSIWYG. The markup will specify *where* exactly is this
> > content, and what shouldn't be changed.
>
> About that "flag", you seems to plan a boolean but I feel something
> more generic that we want to introduce since a long time would be
> better: make the content descriptor return a type like parameters
> descriptors do. The kind of inline editing you have in mind right now
> would then be associated to the type List<Block> for example (or
> CompositeBlock



> or some another type if we want to differentiate
> between wiki content modified by the macro and wiki content not
> modified by the macro


We need this differentiation.


> ). The other types would be used in other use
> cases (syntax coloring for scripts, json editor, etc.). The idea of
> using Java type is to be consistent with parameters and reuse existing
> the displayers in the macro modal window for example but it can cover
> this need too.
>
> >
> > I guess that if the flag is set and the markup is not present, then the
> > entire content is considered as editable.
> >
> > >
> > > Is that because you want to be finer-grained and have macro content
> which can have parts editable with the WYSIWYG while having other parts of
> the content not editable (for example)?
> >
> > It's exactly why yes. On my example, the macro user won't be able to
> > change the content of the title.
> >
> > >
> > > Technically Macros don’t generate HTML, only XDOM. So in order to make
> it easier for java macro developers, I’d suggest to introduce some new
> wrapping Block to indicate this information. We might need something
> similar for wiki macros too, to make it more reusable and typed.
> >
> > I'd need to look more on wrapping block but after a quick overlook it
> > seems to make sense indeed.
> >
> > >
> > >> About parameters, our idea was to define a new metadata attribute and
> to ask users to use it for specifying the content is editable, such as for
> a parameter named foo:
> > >>
> > >> <span class="editable-content" data-parameter="foo">my foo parameter
> value</span>
> > >
> > > What’s your idea for editing parameters requiring WYSIWYG? How do you
> present them in the UI? Do you have any mockup?
> >
> > I don't have any mockup right now. FTM I see it like this:
> >   - when creating the macro, the current text input are improved with
> > the CKEditor for the editable content/parameters
> >   - when editing the macro, you stay in the main editor UI, but the
> > content is now editable instead of opening back the macro UI
> >
> > >
> > >> However I don't know right now how the editor would manage cases such
> as:
> > >> <span class="editable-content">Some content with <span
> class="editable-content" data-parameter="myparameter">a
> parameter</span></span>
> > >>
> > >> So:
> > >>   1. Do you agree on the usage of a class named "editable-content"
> which would be used as a tag to allow inline edition?
> > >
> > > Small details, there’s already the “contenteditable” notion that
> exists (see https://developer.mozilla.org/fr/docs/Web/HTML/Attributs_
> universels/contenteditable) so “editable-content” is quite close. Maybe
> we should have something more xwiki-specific? or more WYSIWYG-specific?
> Like “editable-wysiwyg” or “wysiwyg-editable”.
> >
> > I'm open to suggestion on this one. "wysiwyg-editable" could be nice.
> > >
> > > My main comment is what I put above: how do we make it easy for macro
> developers to specify this information.
> > >
> > >>   2. WDYT about using a data-parameter and this class for inline
> editing of parameters?
> > >
> > > Before answering that part, I would need to understand what’s the
> proposal in term of UI.
> > >
> > > Note that the main use case is for content but it’s nice if you can
> also support parameters. Now, accepting markup in parameters is not really
> a great use case IMO and is usually a design issue so I’m not sure we
> should spend that much time in supporting that. WDYT?
> >
> > We just discuss about macro parameters with Ludovic and apparently they
> > cannot support line returns, so we might have to use a custom editor for
> > those.
> >
> > >
> > > The only macro parameter I know ATM that supports markup is the
> “title” param of the {{box}} macro and I think it’s badly designed. Note:
> if you check the recent {{figure}} macro, I implemented this need by having
> a {{figureCaption}} nested macro.
> > >
> > > BTW this raises a question, will you support WYSIWYG editing of nested
> macros?
> >
> > Not for the moment.
> >
> > Simon
> > >
> > > Thanks
> > > -Vincent
> > >
> > >> Thanks,
> > >> Simon
> > >
> > > [snip]
> > >
> >
> > --
> > Simon Urli
> > Software Engineer at XWiki SAS
> > [hidden email]
> > More about us at http://www.xwiki.com
>
>
>
> --
> Thomas Mortagne
>
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for Macro inline edition

Thomas Mortagne
Administrator
On Mon, Sep 10, 2018 at 2:56 PM Marius Dumitru Florea
<[hidden email]> wrote:

>
> On Mon, Sep 10, 2018 at 3:42 PM, Thomas Mortagne <[hidden email]>
> wrote:
>
> > On Mon, Sep 10, 2018 at 2:13 PM Simon Urli <[hidden email]> wrote:
> > >
> > >
> > >
> > > On 9/10/18 1:35 PM, Vincent Massol wrote:
> > > > Hi Simon,
> > > >
> > > >> On 10 Sep 2018, at 13:05, Simon Urli <[hidden email]> wrote:
> > > >>
> > > >> Hi everyone,
> > > >>
> > > >> I'm working on the roadmap issues related to the inline edition with
> > WYSIWYG editor for macro content and macro parameters.
> > > >
> > > > Cool :) We've been waiting for a long time about this feature! See
> > below.
> > > >
> > > >> The first step is to add a flag to allow user specify that a content
> > or a parameter can be edited inline with the WYSIWYG editor.
> > > >> The second step is to allow the CKEditor to detect where the content
> > and/or parameters should be edited.
> > > >> Let's take the exampe of a simple macro without any parameter, which
> > currently produces this code:
> > > >>
> > > >> <div class="box infomessage">
> > > >>   <div class="title">
> > > >>     <span class="icon info"></span>
> > > >>     some title
> > > >>   </div>
> > > >>   Some content
> > > >> </div>
> > > >>
> > > >> We propose (me & Marius) to ask users to add a wrapper with a
> > specific class around the content to tell the editor it should only allow
> > editing this content, e.g.:
> > > >>
> > > >> <div class="box infomessage">
> > > >>   <div class="title">
> > > >>     <span class="icon info"></span>
> > > >>     some title
> > > >>   </div>
> > > >>   <span class="editable-content">Some content</span>
> > > >> </div>
> > > >
> > > > By “users”, I guess you mean macro developers?
> > >
> > > Here yes it's the macro developer. I'll try to be more specific in my
> > > answers.
> > >
> > > >
> > > > So if I understand you well, you’re not planning to add a
> > getter/setters to the Macro descriptor, to tell that the macro content
> > contains wiki markup and that it should be editable in the WYSIWYG editor?
> > >
> > > Actually we're planning to add the getter/setter **and** the specific
> > > markup for the editor. The getter/setter (which I called the flag
> > > above), is here to specify that the macro will contain inline editable
> > > content in WYSIWYG. The markup will specify *where* exactly is this
> > > content, and what shouldn't be changed.
> >
> > About that "flag", you seems to plan a boolean but I feel something
> > more generic that we want to introduce since a long time would be
> > better: make the content descriptor return a type like parameters
> > descriptors do. The kind of inline editing you have in mind right now
> > would then be associated to the type List<Block> for example (or
> > CompositeBlock
>
>
>
> > or some another type if we want to differentiate
> > between wiki content modified by the macro and wiki content not
> > modified by the macro
>
>
> We need this differentiation.

Sure but as I said you can differentiate using types too and we need
content types for other use cases so it's a good occasion. Also when
you use the type you can differentiate between wiki content and HTML
content and support inline editing of HTML macro in the same system
for example.

>
>
> > ). The other types would be used in other use
> > cases (syntax coloring for scripts, json editor, etc.). The idea of
> > using Java type is to be consistent with parameters and reuse existing
> > the displayers in the macro modal window for example but it can cover
> > this need too.
> >
> > >
> > > I guess that if the flag is set and the markup is not present, then the
> > > entire content is considered as editable.
> > >
> > > >
> > > > Is that because you want to be finer-grained and have macro content
> > which can have parts editable with the WYSIWYG while having other parts of
> > the content not editable (for example)?
> > >
> > > It's exactly why yes. On my example, the macro user won't be able to
> > > change the content of the title.
> > >
> > > >
> > > > Technically Macros don’t generate HTML, only XDOM. So in order to make
> > it easier for java macro developers, I’d suggest to introduce some new
> > wrapping Block to indicate this information. We might need something
> > similar for wiki macros too, to make it more reusable and typed.
> > >
> > > I'd need to look more on wrapping block but after a quick overlook it
> > > seems to make sense indeed.
> > >
> > > >
> > > >> About parameters, our idea was to define a new metadata attribute and
> > to ask users to use it for specifying the content is editable, such as for
> > a parameter named foo:
> > > >>
> > > >> <span class="editable-content" data-parameter="foo">my foo parameter
> > value</span>
> > > >
> > > > What’s your idea for editing parameters requiring WYSIWYG? How do you
> > present them in the UI? Do you have any mockup?
> > >
> > > I don't have any mockup right now. FTM I see it like this:
> > >   - when creating the macro, the current text input are improved with
> > > the CKEditor for the editable content/parameters
> > >   - when editing the macro, you stay in the main editor UI, but the
> > > content is now editable instead of opening back the macro UI
> > >
> > > >
> > > >> However I don't know right now how the editor would manage cases such
> > as:
> > > >> <span class="editable-content">Some content with <span
> > class="editable-content" data-parameter="myparameter">a
> > parameter</span></span>
> > > >>
> > > >> So:
> > > >>   1. Do you agree on the usage of a class named "editable-content"
> > which would be used as a tag to allow inline edition?
> > > >
> > > > Small details, there’s already the “contenteditable” notion that
> > exists (see https://developer.mozilla.org/fr/docs/Web/HTML/Attributs_
> > universels/contenteditable) so “editable-content” is quite close. Maybe
> > we should have something more xwiki-specific? or more WYSIWYG-specific?
> > Like “editable-wysiwyg” or “wysiwyg-editable”.
> > >
> > > I'm open to suggestion on this one. "wysiwyg-editable" could be nice.
> > > >
> > > > My main comment is what I put above: how do we make it easy for macro
> > developers to specify this information.
> > > >
> > > >>   2. WDYT about using a data-parameter and this class for inline
> > editing of parameters?
> > > >
> > > > Before answering that part, I would need to understand what’s the
> > proposal in term of UI.
> > > >
> > > > Note that the main use case is for content but it’s nice if you can
> > also support parameters. Now, accepting markup in parameters is not really
> > a great use case IMO and is usually a design issue so I’m not sure we
> > should spend that much time in supporting that. WDYT?
> > >
> > > We just discuss about macro parameters with Ludovic and apparently they
> > > cannot support line returns, so we might have to use a custom editor for
> > > those.
> > >
> > > >
> > > > The only macro parameter I know ATM that supports markup is the
> > “title” param of the {{box}} macro and I think it’s badly designed. Note:
> > if you check the recent {{figure}} macro, I implemented this need by having
> > a {{figureCaption}} nested macro.
> > > >
> > > > BTW this raises a question, will you support WYSIWYG editing of nested
> > macros?
> > >
> > > Not for the moment.
> > >
> > > Simon
> > > >
> > > > Thanks
> > > > -Vincent
> > > >
> > > >> Thanks,
> > > >> Simon
> > > >
> > > > [snip]
> > > >
> > >
> > > --
> > > Simon Urli
> > > Software Engineer at XWiki SAS
> > > [hidden email]
> > > More about us at http://www.xwiki.com
> >
> >
> >
> > --
> > Thomas Mortagne
> >



--
Thomas Mortagne
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for Macro inline edition

Marius Dumitru Florea
On Mon, Sep 10, 2018 at 4:07 PM, Thomas Mortagne <[hidden email]>
wrote:

> On Mon, Sep 10, 2018 at 2:56 PM Marius Dumitru Florea
> <[hidden email]> wrote:
> >
> > On Mon, Sep 10, 2018 at 3:42 PM, Thomas Mortagne <
> [hidden email]>
> > wrote:
> >
> > > On Mon, Sep 10, 2018 at 2:13 PM Simon Urli <[hidden email]>
> wrote:
> > > >
> > > >
> > > >
> > > > On 9/10/18 1:35 PM, Vincent Massol wrote:
> > > > > Hi Simon,
> > > > >
> > > > >> On 10 Sep 2018, at 13:05, Simon Urli <[hidden email]>
> wrote:
> > > > >>
> > > > >> Hi everyone,
> > > > >>
> > > > >> I'm working on the roadmap issues related to the inline edition
> with
> > > WYSIWYG editor for macro content and macro parameters.
> > > > >
> > > > > Cool :) We've been waiting for a long time about this feature! See
> > > below.
> > > > >
> > > > >> The first step is to add a flag to allow user specify that a
> content
> > > or a parameter can be edited inline with the WYSIWYG editor.
> > > > >> The second step is to allow the CKEditor to detect where the
> content
> > > and/or parameters should be edited.
> > > > >> Let's take the exampe of a simple macro without any parameter,
> which
> > > currently produces this code:
> > > > >>
> > > > >> <div class="box infomessage">
> > > > >>   <div class="title">
> > > > >>     <span class="icon info"></span>
> > > > >>     some title
> > > > >>   </div>
> > > > >>   Some content
> > > > >> </div>
> > > > >>
> > > > >> We propose (me & Marius) to ask users to add a wrapper with a
> > > specific class around the content to tell the editor it should only
> allow
> > > editing this content, e.g.:
> > > > >>
> > > > >> <div class="box infomessage">
> > > > >>   <div class="title">
> > > > >>     <span class="icon info"></span>
> > > > >>     some title
> > > > >>   </div>
> > > > >>   <span class="editable-content">Some content</span>
> > > > >> </div>
> > > > >
> > > > > By “users”, I guess you mean macro developers?
> > > >
> > > > Here yes it's the macro developer. I'll try to be more specific in my
> > > > answers.
> > > >
> > > > >
> > > > > So if I understand you well, you’re not planning to add a
> > > getter/setters to the Macro descriptor, to tell that the macro content
> > > contains wiki markup and that it should be editable in the WYSIWYG
> editor?
> > > >
> > > > Actually we're planning to add the getter/setter **and** the specific
> > > > markup for the editor. The getter/setter (which I called the flag
> > > > above), is here to specify that the macro will contain inline
> editable
> > > > content in WYSIWYG. The markup will specify *where* exactly is this
> > > > content, and what shouldn't be changed.
> > >
> > > About that "flag", you seems to plan a boolean but I feel something
> > > more generic that we want to introduce since a long time would be
> > > better: make the content descriptor return a type like parameters
> > > descriptors do. The kind of inline editing you have in mind right now
> > > would then be associated to the type List<Block> for example (or
> > > CompositeBlock
> >
> >
> >
> > > or some another type if we want to differentiate
> > > between wiki content modified by the macro and wiki content not
> > > modified by the macro
> >
> >
> > We need this differentiation.
>
> Sure but as I said you can differentiate using types too and we need
> content types for other use cases so it's a good occasion. Also when
> you use the type you can differentiate between wiki content and HTML
> content and support inline editing of HTML macro in the same system
> for example.
>

I'm not against your proposal. It's a bit more work though, to define the
types, but I suppose it's worth the effort.


>
> >
> >
> > > ). The other types would be used in other use
> > > cases (syntax coloring for scripts, json editor, etc.). The idea of
> > > using Java type is to be consistent with parameters and reuse existing
> > > the displayers in the macro modal window for example but it can cover
> > > this need too.
> > >
> > > >
> > > > I guess that if the flag is set and the markup is not present, then
> the
> > > > entire content is considered as editable.
> > > >
> > > > >
> > > > > Is that because you want to be finer-grained and have macro content
> > > which can have parts editable with the WYSIWYG while having other
> parts of
> > > the content not editable (for example)?
> > > >
> > > > It's exactly why yes. On my example, the macro user won't be able to
> > > > change the content of the title.
> > > >
> > > > >
> > > > > Technically Macros don’t generate HTML, only XDOM. So in order to
> make
> > > it easier for java macro developers, I’d suggest to introduce some new
> > > wrapping Block to indicate this information. We might need something
> > > similar for wiki macros too, to make it more reusable and typed.
> > > >
> > > > I'd need to look more on wrapping block but after a quick overlook it
> > > > seems to make sense indeed.
> > > >
> > > > >
> > > > >> About parameters, our idea was to define a new metadata attribute
> and
> > > to ask users to use it for specifying the content is editable, such as
> for
> > > a parameter named foo:
> > > > >>
> > > > >> <span class="editable-content" data-parameter="foo">my foo
> parameter
> > > value</span>
> > > > >
> > > > > What’s your idea for editing parameters requiring WYSIWYG? How do
> you
> > > present them in the UI? Do you have any mockup?
> > > >
> > > > I don't have any mockup right now. FTM I see it like this:
> > > >   - when creating the macro, the current text input are improved with
> > > > the CKEditor for the editable content/parameters
> > > >   - when editing the macro, you stay in the main editor UI, but the
> > > > content is now editable instead of opening back the macro UI
> > > >
> > > > >
> > > > >> However I don't know right now how the editor would manage cases
> such
> > > as:
> > > > >> <span class="editable-content">Some content with <span
> > > class="editable-content" data-parameter="myparameter">a
> > > parameter</span></span>
> > > > >>
> > > > >> So:
> > > > >>   1. Do you agree on the usage of a class named "editable-content"
> > > which would be used as a tag to allow inline edition?
> > > > >
> > > > > Small details, there’s already the “contenteditable” notion that
> > > exists (see https://developer.mozilla.org/fr/docs/Web/HTML/Attributs_
> > > universels/contenteditable) so “editable-content” is quite close. Maybe
> > > we should have something more xwiki-specific? or more WYSIWYG-specific?
> > > Like “editable-wysiwyg” or “wysiwyg-editable”.
> > > >
> > > > I'm open to suggestion on this one. "wysiwyg-editable" could be nice.
> > > > >
> > > > > My main comment is what I put above: how do we make it easy for
> macro
> > > developers to specify this information.
> > > > >
> > > > >>   2. WDYT about using a data-parameter and this class for inline
> > > editing of parameters?
> > > > >
> > > > > Before answering that part, I would need to understand what’s the
> > > proposal in term of UI.
> > > > >
> > > > > Note that the main use case is for content but it’s nice if you can
> > > also support parameters. Now, accepting markup in parameters is not
> really
> > > a great use case IMO and is usually a design issue so I’m not sure we
> > > should spend that much time in supporting that. WDYT?
> > > >
> > > > We just discuss about macro parameters with Ludovic and apparently
> they
> > > > cannot support line returns, so we might have to use a custom editor
> for
> > > > those.
> > > >
> > > > >
> > > > > The only macro parameter I know ATM that supports markup is the
> > > “title” param of the {{box}} macro and I think it’s badly designed.
> Note:
> > > if you check the recent {{figure}} macro, I implemented this need by
> having
> > > a {{figureCaption}} nested macro.
> > > > >
> > > > > BTW this raises a question, will you support WYSIWYG editing of
> nested
> > > macros?
> > > >
> > > > Not for the moment.
> > > >
> > > > Simon
> > > > >
> > > > > Thanks
> > > > > -Vincent
> > > > >
> > > > >> Thanks,
> > > > >> Simon
> > > > >
> > > > > [snip]
> > > > >
> > > >
> > > > --
> > > > Simon Urli
> > > > Software Engineer at XWiki SAS
> > > > [hidden email]
> > > > More about us at http://www.xwiki.com
> > >
> > >
> > >
> > > --
> > > Thomas Mortagne
> > >
>
>
>
> --
> Thomas Mortagne
>
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for Macro inline edition

Simon Urli


On 9/10/18 3:24 PM, Marius Dumitru Florea wrote:

> On Mon, Sep 10, 2018 at 4:07 PM, Thomas Mortagne <[hidden email]>
> wrote:
>
>> On Mon, Sep 10, 2018 at 2:56 PM Marius Dumitru Florea
>> <[hidden email]> wrote:
>>>
>>> On Mon, Sep 10, 2018 at 3:42 PM, Thomas Mortagne <
>> [hidden email]>
>>> wrote:
>>>
>>>> On Mon, Sep 10, 2018 at 2:13 PM Simon Urli <[hidden email]>
>> wrote:
>>>>>
>>>>>
>>>>>
>>>>> On 9/10/18 1:35 PM, Vincent Massol wrote:
>>>>>> Hi Simon,
>>>>>>
>>>>>>> On 10 Sep 2018, at 13:05, Simon Urli <[hidden email]>
>> wrote:
>>>>>>>
>>>>>>> Hi everyone,
>>>>>>>
>>>>>>> I'm working on the roadmap issues related to the inline edition
>> with
>>>> WYSIWYG editor for macro content and macro parameters.
>>>>>>
>>>>>> Cool :) We've been waiting for a long time about this feature! See
>>>> below.
>>>>>>
>>>>>>> The first step is to add a flag to allow user specify that a
>> content
>>>> or a parameter can be edited inline with the WYSIWYG editor.
>>>>>>> The second step is to allow the CKEditor to detect where the
>> content
>>>> and/or parameters should be edited.
>>>>>>> Let's take the exampe of a simple macro without any parameter,
>> which
>>>> currently produces this code:
>>>>>>>
>>>>>>> <div class="box infomessage">
>>>>>>>    <div class="title">
>>>>>>>      <span class="icon info"></span>
>>>>>>>      some title
>>>>>>>    </div>
>>>>>>>    Some content
>>>>>>> </div>
>>>>>>>
>>>>>>> We propose (me & Marius) to ask users to add a wrapper with a
>>>> specific class around the content to tell the editor it should only
>> allow
>>>> editing this content, e.g.:
>>>>>>>
>>>>>>> <div class="box infomessage">
>>>>>>>    <div class="title">
>>>>>>>      <span class="icon info"></span>
>>>>>>>      some title
>>>>>>>    </div>
>>>>>>>    <span class="editable-content">Some content</span>
>>>>>>> </div>
>>>>>>
>>>>>> By “users”, I guess you mean macro developers?
>>>>>
>>>>> Here yes it's the macro developer. I'll try to be more specific in my
>>>>> answers.
>>>>>
>>>>>>
>>>>>> So if I understand you well, you’re not planning to add a
>>>> getter/setters to the Macro descriptor, to tell that the macro content
>>>> contains wiki markup and that it should be editable in the WYSIWYG
>> editor?
>>>>>
>>>>> Actually we're planning to add the getter/setter **and** the specific
>>>>> markup for the editor. The getter/setter (which I called the flag
>>>>> above), is here to specify that the macro will contain inline
>> editable
>>>>> content in WYSIWYG. The markup will specify *where* exactly is this
>>>>> content, and what shouldn't be changed.
>>>>
>>>> About that "flag", you seems to plan a boolean but I feel something
>>>> more generic that we want to introduce since a long time would be
>>>> better: make the content descriptor return a type like parameters
>>>> descriptors do. The kind of inline editing you have in mind right now
>>>> would then be associated to the type List<Block> for example (or
>>>> CompositeBlock
>>>
>>>
>>>
>>>> or some another type if we want to differentiate
>>>> between wiki content modified by the macro and wiki content not
>>>> modified by the macro
>>>
>>>
>>> We need this differentiation.
>>
>> Sure but as I said you can differentiate using types too and we need
>> content types for other use cases so it's a good occasion. Also when
>> you use the type you can differentiate between wiki content and HTML
>> content and support inline editing of HTML macro in the same system
>> for example.
>>
>
> I'm not against your proposal. It's a bit more work though, to define the
> types, but I suppose it's worth the effort.
>
>

So if I follow the idea would be to use this type defined for the
content descriptor to specify the behaviour of the editor: e.g. if the
content descriptor is defined as an html content, then the html editor
would be used, if it's defined as an inline content, then it would be an
editor with limitation to clean html and line returns, etc.

Still it does not change the need to specify which elements of the
content are editable, right?

Moreover I've the feeling that the parameters are already not supporting
the different types for edition (e.g. a boolean parameter only shows a
text input). So wouldn't it be a priority before putting a type on the
content descriptor itself?

>>
>>>
>>>
>>>> ). The other types would be used in other use
>>>> cases (syntax coloring for scripts, json editor, etc.). The idea of
>>>> using Java type is to be consistent with parameters and reuse existing
>>>> the displayers in the macro modal window for example but it can cover
>>>> this need too.
>>>>
>>>>>
>>>>> I guess that if the flag is set and the markup is not present, then
>> the
>>>>> entire content is considered as editable.
>>>>>
>>>>>>
>>>>>> Is that because you want to be finer-grained and have macro content
>>>> which can have parts editable with the WYSIWYG while having other
>> parts of
>>>> the content not editable (for example)?
>>>>>
>>>>> It's exactly why yes. On my example, the macro user won't be able to
>>>>> change the content of the title.
>>>>>
>>>>>>
>>>>>> Technically Macros don’t generate HTML, only XDOM. So in order to
>> make
>>>> it easier for java macro developers, I’d suggest to introduce some new
>>>> wrapping Block to indicate this information. We might need something
>>>> similar for wiki macros too, to make it more reusable and typed.
>>>>>
>>>>> I'd need to look more on wrapping block but after a quick overlook it
>>>>> seems to make sense indeed.
>>>>>
>>>>>>
>>>>>>> About parameters, our idea was to define a new metadata attribute
>> and
>>>> to ask users to use it for specifying the content is editable, such as
>> for
>>>> a parameter named foo:
>>>>>>>
>>>>>>> <span class="editable-content" data-parameter="foo">my foo
>> parameter
>>>> value</span>
>>>>>>
>>>>>> What’s your idea for editing parameters requiring WYSIWYG? How do
>> you
>>>> present them in the UI? Do you have any mockup?
>>>>>
>>>>> I don't have any mockup right now. FTM I see it like this:
>>>>>    - when creating the macro, the current text input are improved with
>>>>> the CKEditor for the editable content/parameters
>>>>>    - when editing the macro, you stay in the main editor UI, but the
>>>>> content is now editable instead of opening back the macro UI
>>>>>
>>>>>>
>>>>>>> However I don't know right now how the editor would manage cases
>> such
>>>> as:
>>>>>>> <span class="editable-content">Some content with <span
>>>> class="editable-content" data-parameter="myparameter">a
>>>> parameter</span></span>
>>>>>>>
>>>>>>> So:
>>>>>>>    1. Do you agree on the usage of a class named "editable-content"
>>>> which would be used as a tag to allow inline edition?
>>>>>>
>>>>>> Small details, there’s already the “contenteditable” notion that
>>>> exists (see https://developer.mozilla.org/fr/docs/Web/HTML/Attributs_
>>>> universels/contenteditable) so “editable-content” is quite close. Maybe
>>>> we should have something more xwiki-specific? or more WYSIWYG-specific?
>>>> Like “editable-wysiwyg” or “wysiwyg-editable”.
>>>>>
>>>>> I'm open to suggestion on this one. "wysiwyg-editable" could be nice.
>>>>>>
>>>>>> My main comment is what I put above: how do we make it easy for
>> macro
>>>> developers to specify this information.
>>>>>>
>>>>>>>    2. WDYT about using a data-parameter and this class for inline
>>>> editing of parameters?
>>>>>>
>>>>>> Before answering that part, I would need to understand what’s the
>>>> proposal in term of UI.
>>>>>>
>>>>>> Note that the main use case is for content but it’s nice if you can
>>>> also support parameters. Now, accepting markup in parameters is not
>> really
>>>> a great use case IMO and is usually a design issue so I’m not sure we
>>>> should spend that much time in supporting that. WDYT?
>>>>>
>>>>> We just discuss about macro parameters with Ludovic and apparently
>> they
>>>>> cannot support line returns, so we might have to use a custom editor
>> for
>>>>> those.
>>>>>
>>>>>>
>>>>>> The only macro parameter I know ATM that supports markup is the
>>>> “title” param of the {{box}} macro and I think it’s badly designed.
>> Note:
>>>> if you check the recent {{figure}} macro, I implemented this need by
>> having
>>>> a {{figureCaption}} nested macro.
>>>>>>
>>>>>> BTW this raises a question, will you support WYSIWYG editing of
>> nested
>>>> macros?
>>>>>
>>>>> Not for the moment.
>>>>>
>>>>> Simon
>>>>>>
>>>>>> Thanks
>>>>>> -Vincent
>>>>>>
>>>>>>> Thanks,
>>>>>>> Simon
>>>>>>
>>>>>> [snip]
>>>>>>
>>>>>
>>>>> --
>>>>> Simon Urli
>>>>> Software Engineer at XWiki SAS
>>>>> [hidden email]
>>>>> More about us at http://www.xwiki.com
>>>>
>>>>
>>>>
>>>> --
>>>> Thomas Mortagne
>>>>
>>
>>
>>
>> --
>> Thomas Mortagne
>>

--
Simon Urli
Software Engineer at XWiki SAS
[hidden email]
More about us at http://www.xwiki.com
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for Macro inline edition

Thomas Mortagne
Administrator
On Mon, Sep 10, 2018 at 3:47 PM Simon Urli <[hidden email]> wrote:

>
>
>
> On 9/10/18 3:24 PM, Marius Dumitru Florea wrote:
> > On Mon, Sep 10, 2018 at 4:07 PM, Thomas Mortagne <[hidden email]>
> > wrote:
> >
> >> On Mon, Sep 10, 2018 at 2:56 PM Marius Dumitru Florea
> >> <[hidden email]> wrote:
> >>>
> >>> On Mon, Sep 10, 2018 at 3:42 PM, Thomas Mortagne <
> >> [hidden email]>
> >>> wrote:
> >>>
> >>>> On Mon, Sep 10, 2018 at 2:13 PM Simon Urli <[hidden email]>
> >> wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>> On 9/10/18 1:35 PM, Vincent Massol wrote:
> >>>>>> Hi Simon,
> >>>>>>
> >>>>>>> On 10 Sep 2018, at 13:05, Simon Urli <[hidden email]>
> >> wrote:
> >>>>>>>
> >>>>>>> Hi everyone,
> >>>>>>>
> >>>>>>> I'm working on the roadmap issues related to the inline edition
> >> with
> >>>> WYSIWYG editor for macro content and macro parameters.
> >>>>>>
> >>>>>> Cool :) We've been waiting for a long time about this feature! See
> >>>> below.
> >>>>>>
> >>>>>>> The first step is to add a flag to allow user specify that a
> >> content
> >>>> or a parameter can be edited inline with the WYSIWYG editor.
> >>>>>>> The second step is to allow the CKEditor to detect where the
> >> content
> >>>> and/or parameters should be edited.
> >>>>>>> Let's take the exampe of a simple macro without any parameter,
> >> which
> >>>> currently produces this code:
> >>>>>>>
> >>>>>>> <div class="box infomessage">
> >>>>>>>    <div class="title">
> >>>>>>>      <span class="icon info"></span>
> >>>>>>>      some title
> >>>>>>>    </div>
> >>>>>>>    Some content
> >>>>>>> </div>
> >>>>>>>
> >>>>>>> We propose (me & Marius) to ask users to add a wrapper with a
> >>>> specific class around the content to tell the editor it should only
> >> allow
> >>>> editing this content, e.g.:
> >>>>>>>
> >>>>>>> <div class="box infomessage">
> >>>>>>>    <div class="title">
> >>>>>>>      <span class="icon info"></span>
> >>>>>>>      some title
> >>>>>>>    </div>
> >>>>>>>    <span class="editable-content">Some content</span>
> >>>>>>> </div>
> >>>>>>
> >>>>>> By “users”, I guess you mean macro developers?
> >>>>>
> >>>>> Here yes it's the macro developer. I'll try to be more specific in my
> >>>>> answers.
> >>>>>
> >>>>>>
> >>>>>> So if I understand you well, you’re not planning to add a
> >>>> getter/setters to the Macro descriptor, to tell that the macro content
> >>>> contains wiki markup and that it should be editable in the WYSIWYG
> >> editor?
> >>>>>
> >>>>> Actually we're planning to add the getter/setter **and** the specific
> >>>>> markup for the editor. The getter/setter (which I called the flag
> >>>>> above), is here to specify that the macro will contain inline
> >> editable
> >>>>> content in WYSIWYG. The markup will specify *where* exactly is this
> >>>>> content, and what shouldn't be changed.
> >>>>
> >>>> About that "flag", you seems to plan a boolean but I feel something
> >>>> more generic that we want to introduce since a long time would be
> >>>> better: make the content descriptor return a type like parameters
> >>>> descriptors do. The kind of inline editing you have in mind right now
> >>>> would then be associated to the type List<Block> for example (or
> >>>> CompositeBlock
> >>>
> >>>
> >>>
> >>>> or some another type if we want to differentiate
> >>>> between wiki content modified by the macro and wiki content not
> >>>> modified by the macro
> >>>
> >>>
> >>> We need this differentiation.
> >>
> >> Sure but as I said you can differentiate using types too and we need
> >> content types for other use cases so it's a good occasion. Also when
> >> you use the type you can differentiate between wiki content and HTML
> >> content and support inline editing of HTML macro in the same system
> >> for example.
> >>
> >
> > I'm not against your proposal. It's a bit more work though, to define the
> > types, but I suppose it's worth the effort.

It's not much more work, just need to define one type for the current
use case ("final" wiki content). Other types can come later when
implementing support for them.

> >
> >
>
> So if I follow the idea would be to use this type defined for the
> content descriptor to specify the behaviour of the editor: e.g. if the
> content descriptor is defined as an html content, then the html editor
> would be used, if it's defined as an inline content, then it would be an
> editor with limitation to clean html and line returns, etc.
>
> Still it does not change the need to specify which elements of the
> content are editable, right?

Sure but that's the "second step". I only talked about replacing the
flag you defined as the first step by a more generic type :)

>
> Moreover I've the feeling that the parameters are already not supporting
> the different types for edition (e.g. a boolean parameter only shows a
> text input). So wouldn't it be a priority before putting a type on the
> content descriptor itself?

The WYSIWYG does miss a lot of displayers and we need work on that for sure but:
* you get a checkbox for boolean properties so the type is taken into account
* having more specific displayers is not a requirement for working on
inline wiki editing

>
> >>
> >>>
> >>>
> >>>> ). The other types would be used in other use
> >>>> cases (syntax coloring for scripts, json editor, etc.). The idea of
> >>>> using Java type is to be consistent with parameters and reuse existing
> >>>> the displayers in the macro modal window for example but it can cover
> >>>> this need too.
> >>>>
> >>>>>
> >>>>> I guess that if the flag is set and the markup is not present, then
> >> the
> >>>>> entire content is considered as editable.
> >>>>>
> >>>>>>
> >>>>>> Is that because you want to be finer-grained and have macro content
> >>>> which can have parts editable with the WYSIWYG while having other
> >> parts of
> >>>> the content not editable (for example)?
> >>>>>
> >>>>> It's exactly why yes. On my example, the macro user won't be able to
> >>>>> change the content of the title.
> >>>>>
> >>>>>>
> >>>>>> Technically Macros don’t generate HTML, only XDOM. So in order to
> >> make
> >>>> it easier for java macro developers, I’d suggest to introduce some new
> >>>> wrapping Block to indicate this information. We might need something
> >>>> similar for wiki macros too, to make it more reusable and typed.
> >>>>>
> >>>>> I'd need to look more on wrapping block but after a quick overlook it
> >>>>> seems to make sense indeed.
> >>>>>
> >>>>>>
> >>>>>>> About parameters, our idea was to define a new metadata attribute
> >> and
> >>>> to ask users to use it for specifying the content is editable, such as
> >> for
> >>>> a parameter named foo:
> >>>>>>>
> >>>>>>> <span class="editable-content" data-parameter="foo">my foo
> >> parameter
> >>>> value</span>
> >>>>>>
> >>>>>> What’s your idea for editing parameters requiring WYSIWYG? How do
> >> you
> >>>> present them in the UI? Do you have any mockup?
> >>>>>
> >>>>> I don't have any mockup right now. FTM I see it like this:
> >>>>>    - when creating the macro, the current text input are improved with
> >>>>> the CKEditor for the editable content/parameters
> >>>>>    - when editing the macro, you stay in the main editor UI, but the
> >>>>> content is now editable instead of opening back the macro UI
> >>>>>
> >>>>>>
> >>>>>>> However I don't know right now how the editor would manage cases
> >> such
> >>>> as:
> >>>>>>> <span class="editable-content">Some content with <span
> >>>> class="editable-content" data-parameter="myparameter">a
> >>>> parameter</span></span>
> >>>>>>>
> >>>>>>> So:
> >>>>>>>    1. Do you agree on the usage of a class named "editable-content"
> >>>> which would be used as a tag to allow inline edition?
> >>>>>>
> >>>>>> Small details, there’s already the “contenteditable” notion that
> >>>> exists (see https://developer.mozilla.org/fr/docs/Web/HTML/Attributs_
> >>>> universels/contenteditable) so “editable-content” is quite close. Maybe
> >>>> we should have something more xwiki-specific? or more WYSIWYG-specific?
> >>>> Like “editable-wysiwyg” or “wysiwyg-editable”.
> >>>>>
> >>>>> I'm open to suggestion on this one. "wysiwyg-editable" could be nice.
> >>>>>>
> >>>>>> My main comment is what I put above: how do we make it easy for
> >> macro
> >>>> developers to specify this information.
> >>>>>>
> >>>>>>>    2. WDYT about using a data-parameter and this class for inline
> >>>> editing of parameters?
> >>>>>>
> >>>>>> Before answering that part, I would need to understand what’s the
> >>>> proposal in term of UI.
> >>>>>>
> >>>>>> Note that the main use case is for content but it’s nice if you can
> >>>> also support parameters. Now, accepting markup in parameters is not
> >> really
> >>>> a great use case IMO and is usually a design issue so I’m not sure we
> >>>> should spend that much time in supporting that. WDYT?
> >>>>>
> >>>>> We just discuss about macro parameters with Ludovic and apparently
> >> they
> >>>>> cannot support line returns, so we might have to use a custom editor
> >> for
> >>>>> those.
> >>>>>
> >>>>>>
> >>>>>> The only macro parameter I know ATM that supports markup is the
> >>>> “title” param of the {{box}} macro and I think it’s badly designed.
> >> Note:
> >>>> if you check the recent {{figure}} macro, I implemented this need by
> >> having
> >>>> a {{figureCaption}} nested macro.
> >>>>>>
> >>>>>> BTW this raises a question, will you support WYSIWYG editing of
> >> nested
> >>>> macros?
> >>>>>
> >>>>> Not for the moment.
> >>>>>
> >>>>> Simon
> >>>>>>
> >>>>>> Thanks
> >>>>>> -Vincent
> >>>>>>
> >>>>>>> Thanks,
> >>>>>>> Simon
> >>>>>>
> >>>>>> [snip]
> >>>>>>
> >>>>>
> >>>>> --
> >>>>> Simon Urli
> >>>>> Software Engineer at XWiki SAS
> >>>>> [hidden email]
> >>>>> More about us at http://www.xwiki.com
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> Thomas Mortagne
> >>>>
> >>
> >>
> >>
> >> --
> >> Thomas Mortagne
> >>
>
> --
> Simon Urli
> Software Engineer at XWiki SAS
> [hidden email]
> More about us at http://www.xwiki.com



--
Thomas Mortagne
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for Macro inline edition

Simon Urli
Hello everyone,

as a follow up of this proposal and the discussion we had, I just
created the following design proposal:

https://design.xwiki.org/xwiki/bin/view/Main/MacroInlineEditingContent/

Let me know what you think about it.

Thanks,
Simon

On 9/10/18 6:46 PM, Thomas Mortagne wrote:

> On Mon, Sep 10, 2018 at 3:47 PM Simon Urli <[hidden email]> wrote:
>>
>>
>>
>> On 9/10/18 3:24 PM, Marius Dumitru Florea wrote:
>>> On Mon, Sep 10, 2018 at 4:07 PM, Thomas Mortagne <[hidden email]>
>>> wrote:
>>>
>>>> On Mon, Sep 10, 2018 at 2:56 PM Marius Dumitru Florea
>>>> <[hidden email]> wrote:
>>>>>
>>>>> On Mon, Sep 10, 2018 at 3:42 PM, Thomas Mortagne <
>>>> [hidden email]>
>>>>> wrote:
>>>>>
>>>>>> On Mon, Sep 10, 2018 at 2:13 PM Simon Urli <[hidden email]>
>>>> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 9/10/18 1:35 PM, Vincent Massol wrote:
>>>>>>>> Hi Simon,
>>>>>>>>
>>>>>>>>> On 10 Sep 2018, at 13:05, Simon Urli <[hidden email]>
>>>> wrote:
>>>>>>>>>
>>>>>>>>> Hi everyone,
>>>>>>>>>
>>>>>>>>> I'm working on the roadmap issues related to the inline edition
>>>> with
>>>>>> WYSIWYG editor for macro content and macro parameters.
>>>>>>>>
>>>>>>>> Cool :) We've been waiting for a long time about this feature! See
>>>>>> below.
>>>>>>>>
>>>>>>>>> The first step is to add a flag to allow user specify that a
>>>> content
>>>>>> or a parameter can be edited inline with the WYSIWYG editor.
>>>>>>>>> The second step is to allow the CKEditor to detect where the
>>>> content
>>>>>> and/or parameters should be edited.
>>>>>>>>> Let's take the exampe of a simple macro without any parameter,
>>>> which
>>>>>> currently produces this code:
>>>>>>>>>
>>>>>>>>> <div class="box infomessage">
>>>>>>>>>     <div class="title">
>>>>>>>>>       <span class="icon info"></span>
>>>>>>>>>       some title
>>>>>>>>>     </div>
>>>>>>>>>     Some content
>>>>>>>>> </div>
>>>>>>>>>
>>>>>>>>> We propose (me & Marius) to ask users to add a wrapper with a
>>>>>> specific class around the content to tell the editor it should only
>>>> allow
>>>>>> editing this content, e.g.:
>>>>>>>>>
>>>>>>>>> <div class="box infomessage">
>>>>>>>>>     <div class="title">
>>>>>>>>>       <span class="icon info"></span>
>>>>>>>>>       some title
>>>>>>>>>     </div>
>>>>>>>>>     <span class="editable-content">Some content</span>
>>>>>>>>> </div>
>>>>>>>>
>>>>>>>> By “users”, I guess you mean macro developers?
>>>>>>>
>>>>>>> Here yes it's the macro developer. I'll try to be more specific in my
>>>>>>> answers.
>>>>>>>
>>>>>>>>
>>>>>>>> So if I understand you well, you’re not planning to add a
>>>>>> getter/setters to the Macro descriptor, to tell that the macro content
>>>>>> contains wiki markup and that it should be editable in the WYSIWYG
>>>> editor?
>>>>>>>
>>>>>>> Actually we're planning to add the getter/setter **and** the specific
>>>>>>> markup for the editor. The getter/setter (which I called the flag
>>>>>>> above), is here to specify that the macro will contain inline
>>>> editable
>>>>>>> content in WYSIWYG. The markup will specify *where* exactly is this
>>>>>>> content, and what shouldn't be changed.
>>>>>>
>>>>>> About that "flag", you seems to plan a boolean but I feel something
>>>>>> more generic that we want to introduce since a long time would be
>>>>>> better: make the content descriptor return a type like parameters
>>>>>> descriptors do. The kind of inline editing you have in mind right now
>>>>>> would then be associated to the type List<Block> for example (or
>>>>>> CompositeBlock
>>>>>
>>>>>
>>>>>
>>>>>> or some another type if we want to differentiate
>>>>>> between wiki content modified by the macro and wiki content not
>>>>>> modified by the macro
>>>>>
>>>>>
>>>>> We need this differentiation.
>>>>
>>>> Sure but as I said you can differentiate using types too and we need
>>>> content types for other use cases so it's a good occasion. Also when
>>>> you use the type you can differentiate between wiki content and HTML
>>>> content and support inline editing of HTML macro in the same system
>>>> for example.
>>>>
>>>
>>> I'm not against your proposal. It's a bit more work though, to define the
>>> types, but I suppose it's worth the effort.
>
> It's not much more work, just need to define one type for the current
> use case ("final" wiki content). Other types can come later when
> implementing support for them.
>
>>>
>>>
>>
>> So if I follow the idea would be to use this type defined for the
>> content descriptor to specify the behaviour of the editor: e.g. if the
>> content descriptor is defined as an html content, then the html editor
>> would be used, if it's defined as an inline content, then it would be an
>> editor with limitation to clean html and line returns, etc.
>>
>> Still it does not change the need to specify which elements of the
>> content are editable, right?
>
> Sure but that's the "second step". I only talked about replacing the
> flag you defined as the first step by a more generic type :)
>
>>
>> Moreover I've the feeling that the parameters are already not supporting
>> the different types for edition (e.g. a boolean parameter only shows a
>> text input). So wouldn't it be a priority before putting a type on the
>> content descriptor itself?
>
> The WYSIWYG does miss a lot of displayers and we need work on that for sure but:
> * you get a checkbox for boolean properties so the type is taken into account
> * having more specific displayers is not a requirement for working on
> inline wiki editing
>
>>
>>>>
>>>>>
>>>>>
>>>>>> ). The other types would be used in other use
>>>>>> cases (syntax coloring for scripts, json editor, etc.). The idea of
>>>>>> using Java type is to be consistent with parameters and reuse existing
>>>>>> the displayers in the macro modal window for example but it can cover
>>>>>> this need too.
>>>>>>
>>>>>>>
>>>>>>> I guess that if the flag is set and the markup is not present, then
>>>> the
>>>>>>> entire content is considered as editable.
>>>>>>>
>>>>>>>>
>>>>>>>> Is that because you want to be finer-grained and have macro content
>>>>>> which can have parts editable with the WYSIWYG while having other
>>>> parts of
>>>>>> the content not editable (for example)?
>>>>>>>
>>>>>>> It's exactly why yes. On my example, the macro user won't be able to
>>>>>>> change the content of the title.
>>>>>>>
>>>>>>>>
>>>>>>>> Technically Macros don’t generate HTML, only XDOM. So in order to
>>>> make
>>>>>> it easier for java macro developers, I’d suggest to introduce some new
>>>>>> wrapping Block to indicate this information. We might need something
>>>>>> similar for wiki macros too, to make it more reusable and typed.
>>>>>>>
>>>>>>> I'd need to look more on wrapping block but after a quick overlook it
>>>>>>> seems to make sense indeed.
>>>>>>>
>>>>>>>>
>>>>>>>>> About parameters, our idea was to define a new metadata attribute
>>>> and
>>>>>> to ask users to use it for specifying the content is editable, such as
>>>> for
>>>>>> a parameter named foo:
>>>>>>>>>
>>>>>>>>> <span class="editable-content" data-parameter="foo">my foo
>>>> parameter
>>>>>> value</span>
>>>>>>>>
>>>>>>>> What’s your idea for editing parameters requiring WYSIWYG? How do
>>>> you
>>>>>> present them in the UI? Do you have any mockup?
>>>>>>>
>>>>>>> I don't have any mockup right now. FTM I see it like this:
>>>>>>>     - when creating the macro, the current text input are improved with
>>>>>>> the CKEditor for the editable content/parameters
>>>>>>>     - when editing the macro, you stay in the main editor UI, but the
>>>>>>> content is now editable instead of opening back the macro UI
>>>>>>>
>>>>>>>>
>>>>>>>>> However I don't know right now how the editor would manage cases
>>>> such
>>>>>> as:
>>>>>>>>> <span class="editable-content">Some content with <span
>>>>>> class="editable-content" data-parameter="myparameter">a
>>>>>> parameter</span></span>
>>>>>>>>>
>>>>>>>>> So:
>>>>>>>>>     1. Do you agree on the usage of a class named "editable-content"
>>>>>> which would be used as a tag to allow inline edition?
>>>>>>>>
>>>>>>>> Small details, there’s already the “contenteditable” notion that
>>>>>> exists (see https://developer.mozilla.org/fr/docs/Web/HTML/Attributs_
>>>>>> universels/contenteditable) so “editable-content” is quite close. Maybe
>>>>>> we should have something more xwiki-specific? or more WYSIWYG-specific?
>>>>>> Like “editable-wysiwyg” or “wysiwyg-editable”.
>>>>>>>
>>>>>>> I'm open to suggestion on this one. "wysiwyg-editable" could be nice.
>>>>>>>>
>>>>>>>> My main comment is what I put above: how do we make it easy for
>>>> macro
>>>>>> developers to specify this information.
>>>>>>>>
>>>>>>>>>     2. WDYT about using a data-parameter and this class for inline
>>>>>> editing of parameters?
>>>>>>>>
>>>>>>>> Before answering that part, I would need to understand what’s the
>>>>>> proposal in term of UI.
>>>>>>>>
>>>>>>>> Note that the main use case is for content but it’s nice if you can
>>>>>> also support parameters. Now, accepting markup in parameters is not
>>>> really
>>>>>> a great use case IMO and is usually a design issue so I’m not sure we
>>>>>> should spend that much time in supporting that. WDYT?
>>>>>>>
>>>>>>> We just discuss about macro parameters with Ludovic and apparently
>>>> they
>>>>>>> cannot support line returns, so we might have to use a custom editor
>>>> for
>>>>>>> those.
>>>>>>>
>>>>>>>>
>>>>>>>> The only macro parameter I know ATM that supports markup is the
>>>>>> “title” param of the {{box}} macro and I think it’s badly designed.
>>>> Note:
>>>>>> if you check the recent {{figure}} macro, I implemented this need by
>>>> having
>>>>>> a {{figureCaption}} nested macro.
>>>>>>>>
>>>>>>>> BTW this raises a question, will you support WYSIWYG editing of
>>>> nested
>>>>>> macros?
>>>>>>>
>>>>>>> Not for the moment.
>>>>>>>
>>>>>>> Simon
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>> -Vincent
>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Simon
>>>>>>>>
>>>>>>>> [snip]
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Simon Urli
>>>>>>> Software Engineer at XWiki SAS
>>>>>>> [hidden email]
>>>>>>> More about us at http://www.xwiki.com
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Thomas Mortagne
>>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Thomas Mortagne
>>>>
>>
>> --
>> Simon Urli
>> Software Engineer at XWiki SAS
>> [hidden email]
>> More about us at http://www.xwiki.com
>
>
>

--
Simon Urli
Software Engineer at XWiki SAS
[hidden email]
More about us at http://www.xwiki.com
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for Macro inline edition

Marius Dumitru Florea
On Wed, Sep 12, 2018 at 5:18 PM, Simon Urli <[hidden email]> wrote:

> Hello everyone,
>
> as a follow up of this proposal and the discussion we had, I just created
> the following design proposal:
>
> https://design.xwiki.org/xwiki/bin/view/Main/MacroInlineEditingContent/
>
> Let me know what you think about it.
>

Regarding the Content Descriptor, which Syntax(es) will activate the inline
editing of the macro content? I'm asking because the Syntax of the content
is not the most important part. The most important part for the WYSIWYG
editor is to know if the macro code outputs the macro content without
transforming it. Without this it cannot enable inline editing. If the macro
output is rendered without modifications then the WYSIWYG editor can enable
inline editing but it needs to know in which Syntax to convert the HTML
produced while editing inline. So to summarize:

* First the WYSIWYG editor needs to know if the macro content is rendered
without modifications
* then the WYSIWYG editor needs to know the target Syntax to which to
convert the HTML


>
> Thanks,
> Simon
>
>
> On 9/10/18 6:46 PM, Thomas Mortagne wrote:
>
>> On Mon, Sep 10, 2018 at 3:47 PM Simon Urli <[hidden email]> wrote:
>>
>>>
>>>
>>>
>>> On 9/10/18 3:24 PM, Marius Dumitru Florea wrote:
>>>
>>>> On Mon, Sep 10, 2018 at 4:07 PM, Thomas Mortagne <
>>>> [hidden email]>
>>>> wrote:
>>>>
>>>> On Mon, Sep 10, 2018 at 2:56 PM Marius Dumitru Florea
>>>>> <[hidden email]> wrote:
>>>>>
>>>>>>
>>>>>> On Mon, Sep 10, 2018 at 3:42 PM, Thomas Mortagne <
>>>>>>
>>>>> [hidden email]>
>>>>>
>>>>>> wrote:
>>>>>>
>>>>>> On Mon, Sep 10, 2018 at 2:13 PM Simon Urli <[hidden email]>
>>>>>>>
>>>>>> wrote:
>>>>>
>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 9/10/18 1:35 PM, Vincent Massol wrote:
>>>>>>>>
>>>>>>>>> Hi Simon,
>>>>>>>>>
>>>>>>>>> On 10 Sep 2018, at 13:05, Simon Urli <[hidden email]>
>>>>>>>>>>
>>>>>>>>> wrote:
>>>>>
>>>>>>
>>>>>>>>>> Hi everyone,
>>>>>>>>>>
>>>>>>>>>> I'm working on the roadmap issues related to the inline edition
>>>>>>>>>>
>>>>>>>>> with
>>>>>
>>>>>> WYSIWYG editor for macro content and macro parameters.
>>>>>>>
>>>>>>>>
>>>>>>>>> Cool :) We've been waiting for a long time about this feature! See
>>>>>>>>>
>>>>>>>> below.
>>>>>>>
>>>>>>>>
>>>>>>>>> The first step is to add a flag to allow user specify that a
>>>>>>>>>>
>>>>>>>>> content
>>>>>
>>>>>> or a parameter can be edited inline with the WYSIWYG editor.
>>>>>>>
>>>>>>>> The second step is to allow the CKEditor to detect where the
>>>>>>>>>>
>>>>>>>>> content
>>>>>
>>>>>> and/or parameters should be edited.
>>>>>>>
>>>>>>>> Let's take the exampe of a simple macro without any parameter,
>>>>>>>>>>
>>>>>>>>> which
>>>>>
>>>>>> currently produces this code:
>>>>>>>
>>>>>>>>
>>>>>>>>>> <div class="box infomessage">
>>>>>>>>>>     <div class="title">
>>>>>>>>>>       <span class="icon info"></span>
>>>>>>>>>>       some title
>>>>>>>>>>     </div>
>>>>>>>>>>     Some content
>>>>>>>>>> </div>
>>>>>>>>>>
>>>>>>>>>> We propose (me & Marius) to ask users to add a wrapper with a
>>>>>>>>>>
>>>>>>>>> specific class around the content to tell the editor it should only
>>>>>>>
>>>>>> allow
>>>>>
>>>>>> editing this content, e.g.:
>>>>>>>
>>>>>>>>
>>>>>>>>>> <div class="box infomessage">
>>>>>>>>>>     <div class="title">
>>>>>>>>>>       <span class="icon info"></span>
>>>>>>>>>>       some title
>>>>>>>>>>     </div>
>>>>>>>>>>     <span class="editable-content">Some content</span>
>>>>>>>>>> </div>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> By “users”, I guess you mean macro developers?
>>>>>>>>>
>>>>>>>>
>>>>>>>> Here yes it's the macro developer. I'll try to be more specific in
>>>>>>>> my
>>>>>>>> answers.
>>>>>>>>
>>>>>>>>
>>>>>>>>> So if I understand you well, you’re not planning to add a
>>>>>>>>>
>>>>>>>> getter/setters to the Macro descriptor, to tell that the macro
>>>>>>> content
>>>>>>> contains wiki markup and that it should be editable in the WYSIWYG
>>>>>>>
>>>>>> editor?
>>>>>
>>>>>>
>>>>>>>> Actually we're planning to add the getter/setter **and** the
>>>>>>>> specific
>>>>>>>> markup for the editor. The getter/setter (which I called the flag
>>>>>>>> above), is here to specify that the macro will contain inline
>>>>>>>>
>>>>>>> editable
>>>>>
>>>>>> content in WYSIWYG. The markup will specify *where* exactly is this
>>>>>>>> content, and what shouldn't be changed.
>>>>>>>>
>>>>>>>
>>>>>>> About that "flag", you seems to plan a boolean but I feel something
>>>>>>> more generic that we want to introduce since a long time would be
>>>>>>> better: make the content descriptor return a type like parameters
>>>>>>> descriptors do. The kind of inline editing you have in mind right now
>>>>>>> would then be associated to the type List<Block> for example (or
>>>>>>> CompositeBlock
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> or some another type if we want to differentiate
>>>>>>> between wiki content modified by the macro and wiki content not
>>>>>>> modified by the macro
>>>>>>>
>>>>>>
>>>>>>
>>>>>> We need this differentiation.
>>>>>>
>>>>>
>>>>> Sure but as I said you can differentiate using types too and we need
>>>>> content types for other use cases so it's a good occasion. Also when
>>>>> you use the type you can differentiate between wiki content and HTML
>>>>> content and support inline editing of HTML macro in the same system
>>>>> for example.
>>>>>
>>>>>
>>>> I'm not against your proposal. It's a bit more work though, to define
>>>> the
>>>> types, but I suppose it's worth the effort.
>>>>
>>>
>> It's not much more work, just need to define one type for the current
>> use case ("final" wiki content). Other types can come later when
>> implementing support for them.
>>
>>
>>>>
>>>>
>>> So if I follow the idea would be to use this type defined for the
>>> content descriptor to specify the behaviour of the editor: e.g. if the
>>> content descriptor is defined as an html content, then the html editor
>>> would be used, if it's defined as an inline content, then it would be an
>>> editor with limitation to clean html and line returns, etc.
>>>
>>> Still it does not change the need to specify which elements of the
>>> content are editable, right?
>>>
>>
>> Sure but that's the "second step". I only talked about replacing the
>> flag you defined as the first step by a more generic type :)
>>
>>
>>> Moreover I've the feeling that the parameters are already not supporting
>>> the different types for edition (e.g. a boolean parameter only shows a
>>> text input). So wouldn't it be a priority before putting a type on the
>>> content descriptor itself?
>>>
>>
>> The WYSIWYG does miss a lot of displayers and we need work on that for
>> sure but:
>> * you get a checkbox for boolean properties so the type is taken into
>> account
>> * having more specific displayers is not a requirement for working on
>> inline wiki editing
>>
>>
>>>
>>>>>
>>>>>>
>>>>>> ). The other types would be used in other use
>>>>>>> cases (syntax coloring for scripts, json editor, etc.). The idea of
>>>>>>> using Java type is to be consistent with parameters and reuse
>>>>>>> existing
>>>>>>> the displayers in the macro modal window for example but it can cover
>>>>>>> this need too.
>>>>>>>
>>>>>>>
>>>>>>>> I guess that if the flag is set and the markup is not present, then
>>>>>>>>
>>>>>>> the
>>>>>
>>>>>> entire content is considered as editable.
>>>>>>>>
>>>>>>>>
>>>>>>>>> Is that because you want to be finer-grained and have macro content
>>>>>>>>>
>>>>>>>> which can have parts editable with the WYSIWYG while having other
>>>>>>>
>>>>>> parts of
>>>>>
>>>>>> the content not editable (for example)?
>>>>>>>
>>>>>>>>
>>>>>>>> It's exactly why yes. On my example, the macro user won't be able to
>>>>>>>> change the content of the title.
>>>>>>>>
>>>>>>>>
>>>>>>>>> Technically Macros don’t generate HTML, only XDOM. So in order to
>>>>>>>>>
>>>>>>>> make
>>>>>
>>>>>> it easier for java macro developers, I’d suggest to introduce some new
>>>>>>> wrapping Block to indicate this information. We might need something
>>>>>>> similar for wiki macros too, to make it more reusable and typed.
>>>>>>>
>>>>>>>>
>>>>>>>> I'd need to look more on wrapping block but after a quick overlook
>>>>>>>> it
>>>>>>>> seems to make sense indeed.
>>>>>>>>
>>>>>>>>
>>>>>>>>> About parameters, our idea was to define a new metadata attribute
>>>>>>>>>>
>>>>>>>>> and
>>>>>
>>>>>> to ask users to use it for specifying the content is editable, such as
>>>>>>>
>>>>>> for
>>>>>
>>>>>> a parameter named foo:
>>>>>>>
>>>>>>>>
>>>>>>>>>> <span class="editable-content" data-parameter="foo">my foo
>>>>>>>>>>
>>>>>>>>> parameter
>>>>>
>>>>>> value</span>
>>>>>>>
>>>>>>>>
>>>>>>>>> What’s your idea for editing parameters requiring WYSIWYG? How do
>>>>>>>>>
>>>>>>>> you
>>>>>
>>>>>> present them in the UI? Do you have any mockup?
>>>>>>>
>>>>>>>>
>>>>>>>> I don't have any mockup right now. FTM I see it like this:
>>>>>>>>     - when creating the macro, the current text input are improved
>>>>>>>> with
>>>>>>>> the CKEditor for the editable content/parameters
>>>>>>>>     - when editing the macro, you stay in the main editor UI, but
>>>>>>>> the
>>>>>>>> content is now editable instead of opening back the macro UI
>>>>>>>>
>>>>>>>>
>>>>>>>>> However I don't know right now how the editor would manage cases
>>>>>>>>>>
>>>>>>>>> such
>>>>>
>>>>>> as:
>>>>>>>
>>>>>>>> <span class="editable-content">Some content with <span
>>>>>>>>>>
>>>>>>>>> class="editable-content" data-parameter="myparameter">a
>>>>>>> parameter</span></span>
>>>>>>>
>>>>>>>>
>>>>>>>>>> So:
>>>>>>>>>>     1. Do you agree on the usage of a class named
>>>>>>>>>> "editable-content"
>>>>>>>>>>
>>>>>>>>> which would be used as a tag to allow inline edition?
>>>>>>>
>>>>>>>>
>>>>>>>>> Small details, there’s already the “contenteditable” notion that
>>>>>>>>>
>>>>>>>> exists (see https://developer.mozilla.org/
>>>>>>> fr/docs/Web/HTML/Attributs_
>>>>>>> universels/contenteditable) so “editable-content” is quite close.
>>>>>>> Maybe
>>>>>>> we should have something more xwiki-specific? or more
>>>>>>> WYSIWYG-specific?
>>>>>>> Like “editable-wysiwyg” or “wysiwyg-editable”.
>>>>>>>
>>>>>>>>
>>>>>>>> I'm open to suggestion on this one. "wysiwyg-editable" could be
>>>>>>>> nice.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> My main comment is what I put above: how do we make it easy for
>>>>>>>>>
>>>>>>>> macro
>>>>>
>>>>>> developers to specify this information.
>>>>>>>
>>>>>>>>
>>>>>>>>>     2. WDYT about using a data-parameter and this class for inline
>>>>>>>>>>
>>>>>>>>> editing of parameters?
>>>>>>>
>>>>>>>>
>>>>>>>>> Before answering that part, I would need to understand what’s the
>>>>>>>>>
>>>>>>>> proposal in term of UI.
>>>>>>>
>>>>>>>>
>>>>>>>>> Note that the main use case is for content but it’s nice if you can
>>>>>>>>>
>>>>>>>> also support parameters. Now, accepting markup in parameters is not
>>>>>>>
>>>>>> really
>>>>>
>>>>>> a great use case IMO and is usually a design issue so I’m not sure we
>>>>>>> should spend that much time in supporting that. WDYT?
>>>>>>>
>>>>>>>>
>>>>>>>> We just discuss about macro parameters with Ludovic and apparently
>>>>>>>>
>>>>>>> they
>>>>>
>>>>>> cannot support line returns, so we might have to use a custom editor
>>>>>>>>
>>>>>>> for
>>>>>
>>>>>> those.
>>>>>>>>
>>>>>>>>
>>>>>>>>> The only macro parameter I know ATM that supports markup is the
>>>>>>>>>
>>>>>>>> “title” param of the {{box}} macro and I think it’s badly designed.
>>>>>>>
>>>>>> Note:
>>>>>
>>>>>> if you check the recent {{figure}} macro, I implemented this need by
>>>>>>>
>>>>>> having
>>>>>
>>>>>> a {{figureCaption}} nested macro.
>>>>>>>
>>>>>>>>
>>>>>>>>> BTW this raises a question, will you support WYSIWYG editing of
>>>>>>>>>
>>>>>>>> nested
>>>>>
>>>>>> macros?
>>>>>>>
>>>>>>>>
>>>>>>>> Not for the moment.
>>>>>>>>
>>>>>>>> Simon
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Thanks
>>>>>>>>> -Vincent
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>>> Simon
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> [snip]
>>>>>>>>>
>>>>>>>>>
>>>>>>>> --
>>>>>>>> Simon Urli
>>>>>>>> Software Engineer at XWiki SAS
>>>>>>>> [hidden email]
>>>>>>>> More about us at http://www.xwiki.com
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Thomas Mortagne
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Thomas Mortagne
>>>>>
>>>>>
>>> --
>>> Simon Urli
>>> Software Engineer at XWiki SAS
>>> [hidden email]
>>> More about us at http://www.xwiki.com
>>>
>>
>>
>>
>>
> --
> Simon Urli
> Software Engineer at XWiki SAS
> [hidden email]
> More about us at http://www.xwiki.com
>
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for Macro inline edition

Simon Urli


On 9/12/18 5:02 PM, Marius Dumitru Florea wrote:

> On Wed, Sep 12, 2018 at 5:18 PM, Simon Urli <[hidden email]> wrote:
>
>> Hello everyone,
>>
>> as a follow up of this proposal and the discussion we had, I just created
>> the following design proposal:
>>
>> https://design.xwiki.org/xwiki/bin/view/Main/MacroInlineEditingContent/
>>
>> Let me know what you think about it.
>>
>
> Regarding the Content Descriptor, which Syntax(es) will activate the inline
> editing of the macro content? I'm asking because the Syntax of the content
> is not the most important part. The most important part for the WYSIWYG
> editor is to know if the macro code outputs the macro content without
> transforming it. Without this it cannot enable inline editing. If the macro
> output is rendered without modifications then the WYSIWYG editor can enable
> inline editing but it needs to know in which Syntax to convert the HTML
> produced while editing inline. So to summarize:
>
> * First the WYSIWYG editor needs to know if the macro content is rendered
> without modifications
> * then the WYSIWYG editor needs to know the target Syntax to which to
> convert the HTML
>

The WYSIWYG editor will know if it's editable if it exists a parser and
a renderer for this syntax.
So the target syntax is the given macro syntax.

>
>>
>> Thanks,
>> Simon
>>
>>
>> On 9/10/18 6:46 PM, Thomas Mortagne wrote:
>>
>>> On Mon, Sep 10, 2018 at 3:47 PM Simon Urli <[hidden email]> wrote:
>>>
>>>>
>>>>
>>>>
>>>> On 9/10/18 3:24 PM, Marius Dumitru Florea wrote:
>>>>
>>>>> On Mon, Sep 10, 2018 at 4:07 PM, Thomas Mortagne <
>>>>> [hidden email]>
>>>>> wrote:
>>>>>
>>>>> On Mon, Sep 10, 2018 at 2:56 PM Marius Dumitru Florea
>>>>>> <[hidden email]> wrote:
>>>>>>
>>>>>>>
>>>>>>> On Mon, Sep 10, 2018 at 3:42 PM, Thomas Mortagne <
>>>>>>>
>>>>>> [hidden email]>
>>>>>>
>>>>>>> wrote:
>>>>>>>
>>>>>>> On Mon, Sep 10, 2018 at 2:13 PM Simon Urli <[hidden email]>
>>>>>>>>
>>>>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 9/10/18 1:35 PM, Vincent Massol wrote:
>>>>>>>>>
>>>>>>>>>> Hi Simon,
>>>>>>>>>>
>>>>>>>>>> On 10 Sep 2018, at 13:05, Simon Urli <[hidden email]>
>>>>>>>>>>>
>>>>>>>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>>>>>> Hi everyone,
>>>>>>>>>>>
>>>>>>>>>>> I'm working on the roadmap issues related to the inline edition
>>>>>>>>>>>
>>>>>>>>>> with
>>>>>>
>>>>>>> WYSIWYG editor for macro content and macro parameters.
>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Cool :) We've been waiting for a long time about this feature! See
>>>>>>>>>>
>>>>>>>>> below.
>>>>>>>>
>>>>>>>>>
>>>>>>>>>> The first step is to add a flag to allow user specify that a
>>>>>>>>>>>
>>>>>>>>>> content
>>>>>>
>>>>>>> or a parameter can be edited inline with the WYSIWYG editor.
>>>>>>>>
>>>>>>>>> The second step is to allow the CKEditor to detect where the
>>>>>>>>>>>
>>>>>>>>>> content
>>>>>>
>>>>>>> and/or parameters should be edited.
>>>>>>>>
>>>>>>>>> Let's take the exampe of a simple macro without any parameter,
>>>>>>>>>>>
>>>>>>>>>> which
>>>>>>
>>>>>>> currently produces this code:
>>>>>>>>
>>>>>>>>>
>>>>>>>>>>> <div class="box infomessage">
>>>>>>>>>>>      <div class="title">
>>>>>>>>>>>        <span class="icon info"></span>
>>>>>>>>>>>        some title
>>>>>>>>>>>      </div>
>>>>>>>>>>>      Some content
>>>>>>>>>>> </div>
>>>>>>>>>>>
>>>>>>>>>>> We propose (me & Marius) to ask users to add a wrapper with a
>>>>>>>>>>>
>>>>>>>>>> specific class around the content to tell the editor it should only
>>>>>>>>
>>>>>>> allow
>>>>>>
>>>>>>> editing this content, e.g.:
>>>>>>>>
>>>>>>>>>
>>>>>>>>>>> <div class="box infomessage">
>>>>>>>>>>>      <div class="title">
>>>>>>>>>>>        <span class="icon info"></span>
>>>>>>>>>>>        some title
>>>>>>>>>>>      </div>
>>>>>>>>>>>      <span class="editable-content">Some content</span>
>>>>>>>>>>> </div>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> By “users”, I guess you mean macro developers?
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Here yes it's the macro developer. I'll try to be more specific in
>>>>>>>>> my
>>>>>>>>> answers.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> So if I understand you well, you’re not planning to add a
>>>>>>>>>>
>>>>>>>>> getter/setters to the Macro descriptor, to tell that the macro
>>>>>>>> content
>>>>>>>> contains wiki markup and that it should be editable in the WYSIWYG
>>>>>>>>
>>>>>>> editor?
>>>>>>
>>>>>>>
>>>>>>>>> Actually we're planning to add the getter/setter **and** the
>>>>>>>>> specific
>>>>>>>>> markup for the editor. The getter/setter (which I called the flag
>>>>>>>>> above), is here to specify that the macro will contain inline
>>>>>>>>>
>>>>>>>> editable
>>>>>>
>>>>>>> content in WYSIWYG. The markup will specify *where* exactly is this
>>>>>>>>> content, and what shouldn't be changed.
>>>>>>>>>
>>>>>>>>
>>>>>>>> About that "flag", you seems to plan a boolean but I feel something
>>>>>>>> more generic that we want to introduce since a long time would be
>>>>>>>> better: make the content descriptor return a type like parameters
>>>>>>>> descriptors do. The kind of inline editing you have in mind right now
>>>>>>>> would then be associated to the type List<Block> for example (or
>>>>>>>> CompositeBlock
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> or some another type if we want to differentiate
>>>>>>>> between wiki content modified by the macro and wiki content not
>>>>>>>> modified by the macro
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> We need this differentiation.
>>>>>>>
>>>>>>
>>>>>> Sure but as I said you can differentiate using types too and we need
>>>>>> content types for other use cases so it's a good occasion. Also when
>>>>>> you use the type you can differentiate between wiki content and HTML
>>>>>> content and support inline editing of HTML macro in the same system
>>>>>> for example.
>>>>>>
>>>>>>
>>>>> I'm not against your proposal. It's a bit more work though, to define
>>>>> the
>>>>> types, but I suppose it's worth the effort.
>>>>>
>>>>
>>> It's not much more work, just need to define one type for the current
>>> use case ("final" wiki content). Other types can come later when
>>> implementing support for them.
>>>
>>>
>>>>>
>>>>>
>>>> So if I follow the idea would be to use this type defined for the
>>>> content descriptor to specify the behaviour of the editor: e.g. if the
>>>> content descriptor is defined as an html content, then the html editor
>>>> would be used, if it's defined as an inline content, then it would be an
>>>> editor with limitation to clean html and line returns, etc.
>>>>
>>>> Still it does not change the need to specify which elements of the
>>>> content are editable, right?
>>>>
>>>
>>> Sure but that's the "second step". I only talked about replacing the
>>> flag you defined as the first step by a more generic type :)
>>>
>>>
>>>> Moreover I've the feeling that the parameters are already not supporting
>>>> the different types for edition (e.g. a boolean parameter only shows a
>>>> text input). So wouldn't it be a priority before putting a type on the
>>>> content descriptor itself?
>>>>
>>>
>>> The WYSIWYG does miss a lot of displayers and we need work on that for
>>> sure but:
>>> * you get a checkbox for boolean properties so the type is taken into
>>> account
>>> * having more specific displayers is not a requirement for working on
>>> inline wiki editing
>>>
>>>
>>>>
>>>>>>
>>>>>>>
>>>>>>> ). The other types would be used in other use
>>>>>>>> cases (syntax coloring for scripts, json editor, etc.). The idea of
>>>>>>>> using Java type is to be consistent with parameters and reuse
>>>>>>>> existing
>>>>>>>> the displayers in the macro modal window for example but it can cover
>>>>>>>> this need too.
>>>>>>>>
>>>>>>>>
>>>>>>>>> I guess that if the flag is set and the markup is not present, then
>>>>>>>>>
>>>>>>>> the
>>>>>>
>>>>>>> entire content is considered as editable.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Is that because you want to be finer-grained and have macro content
>>>>>>>>>>
>>>>>>>>> which can have parts editable with the WYSIWYG while having other
>>>>>>>>
>>>>>>> parts of
>>>>>>
>>>>>>> the content not editable (for example)?
>>>>>>>>
>>>>>>>>>
>>>>>>>>> It's exactly why yes. On my example, the macro user won't be able to
>>>>>>>>> change the content of the title.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Technically Macros don’t generate HTML, only XDOM. So in order to
>>>>>>>>>>
>>>>>>>>> make
>>>>>>
>>>>>>> it easier for java macro developers, I’d suggest to introduce some new
>>>>>>>> wrapping Block to indicate this information. We might need something
>>>>>>>> similar for wiki macros too, to make it more reusable and typed.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> I'd need to look more on wrapping block but after a quick overlook
>>>>>>>>> it
>>>>>>>>> seems to make sense indeed.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> About parameters, our idea was to define a new metadata attribute
>>>>>>>>>>>
>>>>>>>>>> and
>>>>>>
>>>>>>> to ask users to use it for specifying the content is editable, such as
>>>>>>>>
>>>>>>> for
>>>>>>
>>>>>>> a parameter named foo:
>>>>>>>>
>>>>>>>>>
>>>>>>>>>>> <span class="editable-content" data-parameter="foo">my foo
>>>>>>>>>>>
>>>>>>>>>> parameter
>>>>>>
>>>>>>> value</span>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>> What’s your idea for editing parameters requiring WYSIWYG? How do
>>>>>>>>>>
>>>>>>>>> you
>>>>>>
>>>>>>> present them in the UI? Do you have any mockup?
>>>>>>>>
>>>>>>>>>
>>>>>>>>> I don't have any mockup right now. FTM I see it like this:
>>>>>>>>>      - when creating the macro, the current text input are improved
>>>>>>>>> with
>>>>>>>>> the CKEditor for the editable content/parameters
>>>>>>>>>      - when editing the macro, you stay in the main editor UI, but
>>>>>>>>> the
>>>>>>>>> content is now editable instead of opening back the macro UI
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> However I don't know right now how the editor would manage cases
>>>>>>>>>>>
>>>>>>>>>> such
>>>>>>
>>>>>>> as:
>>>>>>>>
>>>>>>>>> <span class="editable-content">Some content with <span
>>>>>>>>>>>
>>>>>>>>>> class="editable-content" data-parameter="myparameter">a
>>>>>>>> parameter</span></span>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>>> So:
>>>>>>>>>>>      1. Do you agree on the usage of a class named
>>>>>>>>>>> "editable-content"
>>>>>>>>>>>
>>>>>>>>>> which would be used as a tag to allow inline edition?
>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Small details, there’s already the “contenteditable” notion that
>>>>>>>>>>
>>>>>>>>> exists (see https://developer.mozilla.org/
>>>>>>>> fr/docs/Web/HTML/Attributs_
>>>>>>>> universels/contenteditable) so “editable-content” is quite close.
>>>>>>>> Maybe
>>>>>>>> we should have something more xwiki-specific? or more
>>>>>>>> WYSIWYG-specific?
>>>>>>>> Like “editable-wysiwyg” or “wysiwyg-editable”.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> I'm open to suggestion on this one. "wysiwyg-editable" could be
>>>>>>>>> nice.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> My main comment is what I put above: how do we make it easy for
>>>>>>>>>>
>>>>>>>>> macro
>>>>>>
>>>>>>> developers to specify this information.
>>>>>>>>
>>>>>>>>>
>>>>>>>>>>      2. WDYT about using a data-parameter and this class for inline
>>>>>>>>>>>
>>>>>>>>>> editing of parameters?
>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Before answering that part, I would need to understand what’s the
>>>>>>>>>>
>>>>>>>>> proposal in term of UI.
>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Note that the main use case is for content but it’s nice if you can
>>>>>>>>>>
>>>>>>>>> also support parameters. Now, accepting markup in parameters is not
>>>>>>>>
>>>>>>> really
>>>>>>
>>>>>>> a great use case IMO and is usually a design issue so I’m not sure we
>>>>>>>> should spend that much time in supporting that. WDYT?
>>>>>>>>
>>>>>>>>>
>>>>>>>>> We just discuss about macro parameters with Ludovic and apparently
>>>>>>>>>
>>>>>>>> they
>>>>>>
>>>>>>> cannot support line returns, so we might have to use a custom editor
>>>>>>>>>
>>>>>>>> for
>>>>>>
>>>>>>> those.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> The only macro parameter I know ATM that supports markup is the
>>>>>>>>>>
>>>>>>>>> “title” param of the {{box}} macro and I think it’s badly designed.
>>>>>>>>
>>>>>>> Note:
>>>>>>
>>>>>>> if you check the recent {{figure}} macro, I implemented this need by
>>>>>>>>
>>>>>>> having
>>>>>>
>>>>>>> a {{figureCaption}} nested macro.
>>>>>>>>
>>>>>>>>>
>>>>>>>>>> BTW this raises a question, will you support WYSIWYG editing of
>>>>>>>>>>
>>>>>>>>> nested
>>>>>>
>>>>>>> macros?
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Not for the moment.
>>>>>>>>>
>>>>>>>>> Simon
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Thanks
>>>>>>>>>> -Vincent
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>>> Simon
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> [snip]
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Simon Urli
>>>>>>>>> Software Engineer at XWiki SAS
>>>>>>>>> [hidden email]
>>>>>>>>> More about us at http://www.xwiki.com
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Thomas Mortagne
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Thomas Mortagne
>>>>>>
>>>>>>
>>>> --
>>>> Simon Urli
>>>> Software Engineer at XWiki SAS
>>>> [hidden email]
>>>> More about us at http://www.xwiki.com
>>>>
>>>
>>>
>>>
>>>
>> --
>> Simon Urli
>> Software Engineer at XWiki SAS
>> [hidden email]
>> More about us at http://www.xwiki.com
>>

--
Simon Urli
Software Engineer at XWiki SAS
[hidden email]
More about us at http://www.xwiki.com
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for Macro inline edition

Marius Dumitru Florea
In reply to this post by Marius Dumitru Florea
On Wed, Sep 12, 2018 at 6:02 PM, Marius Dumitru Florea <
[hidden email]> wrote:

> On Wed, Sep 12, 2018 at 5:18 PM, Simon Urli <[hidden email]> wrote:
>
>> Hello everyone,
>>
>> as a follow up of this proposal and the discussion we had, I just created
>> the following design proposal:
>>
>> https://design.xwiki.org/xwiki/bin/view/Main/MacroInlineEditingContent/
>>
>> Let me know what you think about it.
>>
>
> Regarding the Content Descriptor, which Syntax(es) will activate the
> inline editing of the macro content? I'm asking because the Syntax of the
> content is not the most important part. The most important part for the
> WYSIWYG editor is to know if the macro code outputs the macro content
> without transforming it. Without this it cannot enable inline editing. If
> the macro output is rendered without modifications then the WYSIWYG editor
> can enable inline editing but it needs to know in which Syntax to convert
> the HTML produced while editing inline. So to summarize:
>
> * First the WYSIWYG editor needs to know if the macro content is rendered
> without modifications
> * then the WYSIWYG editor needs to know the target Syntax to which to
> convert the HTML
>

Let me try to make this even more clear.  The WYSIWYG editor needs to take
the following decisions:

[OPTIONAL] "Should I display the macro content (plain) text area on the
Macro Edit dialog?"

If the macro content can be edited inline within the editing area then it
probably make sense to not display the text area on the Macro Edit dialog.
But for this we need some *static* information in the macro descriptor to
indicate that the macro content can be edited inline.

[MANDATORY] "Should I enable inline editing for this macro?"

The WYSIWYG editor can scan the macro output DOM (HTML) for some special
markers (attributes) to determine if the macro content can be edited inline

[MANDATORY] "To which syntax do I need to convert the HTML from the macro
content?"

When saving the page the editor needs to convert the macro content from
HTML to some syntax. The target syntax needs to be specified either in the
macro output DOM (HTML) using some attributes or in the macro descriptor.

Hope this helps,
Marius


>
>
>>
>> Thanks,
>> Simon
>>
>>
>> On 9/10/18 6:46 PM, Thomas Mortagne wrote:
>>
>>> On Mon, Sep 10, 2018 at 3:47 PM Simon Urli <[hidden email]> wrote:
>>>
>>>>
>>>>
>>>>
>>>> On 9/10/18 3:24 PM, Marius Dumitru Florea wrote:
>>>>
>>>>> On Mon, Sep 10, 2018 at 4:07 PM, Thomas Mortagne <
>>>>> [hidden email]>
>>>>> wrote:
>>>>>
>>>>> On Mon, Sep 10, 2018 at 2:56 PM Marius Dumitru Florea
>>>>>> <[hidden email]> wrote:
>>>>>>
>>>>>>>
>>>>>>> On Mon, Sep 10, 2018 at 3:42 PM, Thomas Mortagne <
>>>>>>>
>>>>>> [hidden email]>
>>>>>>
>>>>>>> wrote:
>>>>>>>
>>>>>>> On Mon, Sep 10, 2018 at 2:13 PM Simon Urli <[hidden email]>
>>>>>>>>
>>>>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 9/10/18 1:35 PM, Vincent Massol wrote:
>>>>>>>>>
>>>>>>>>>> Hi Simon,
>>>>>>>>>>
>>>>>>>>>> On 10 Sep 2018, at 13:05, Simon Urli <[hidden email]>
>>>>>>>>>>>
>>>>>>>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>>>>>> Hi everyone,
>>>>>>>>>>>
>>>>>>>>>>> I'm working on the roadmap issues related to the inline edition
>>>>>>>>>>>
>>>>>>>>>> with
>>>>>>
>>>>>>> WYSIWYG editor for macro content and macro parameters.
>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Cool :) We've been waiting for a long time about this feature! See
>>>>>>>>>>
>>>>>>>>> below.
>>>>>>>>
>>>>>>>>>
>>>>>>>>>> The first step is to add a flag to allow user specify that a
>>>>>>>>>>>
>>>>>>>>>> content
>>>>>>
>>>>>>> or a parameter can be edited inline with the WYSIWYG editor.
>>>>>>>>
>>>>>>>>> The second step is to allow the CKEditor to detect where the
>>>>>>>>>>>
>>>>>>>>>> content
>>>>>>
>>>>>>> and/or parameters should be edited.
>>>>>>>>
>>>>>>>>> Let's take the exampe of a simple macro without any parameter,
>>>>>>>>>>>
>>>>>>>>>> which
>>>>>>
>>>>>>> currently produces this code:
>>>>>>>>
>>>>>>>>>
>>>>>>>>>>> <div class="box infomessage">
>>>>>>>>>>>     <div class="title">
>>>>>>>>>>>       <span class="icon info"></span>
>>>>>>>>>>>       some title
>>>>>>>>>>>     </div>
>>>>>>>>>>>     Some content
>>>>>>>>>>> </div>
>>>>>>>>>>>
>>>>>>>>>>> We propose (me & Marius) to ask users to add a wrapper with a
>>>>>>>>>>>
>>>>>>>>>> specific class around the content to tell the editor it should
>>>>>>>> only
>>>>>>>>
>>>>>>> allow
>>>>>>
>>>>>>> editing this content, e.g.:
>>>>>>>>
>>>>>>>>>
>>>>>>>>>>> <div class="box infomessage">
>>>>>>>>>>>     <div class="title">
>>>>>>>>>>>       <span class="icon info"></span>
>>>>>>>>>>>       some title
>>>>>>>>>>>     </div>
>>>>>>>>>>>     <span class="editable-content">Some content</span>
>>>>>>>>>>> </div>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> By “users”, I guess you mean macro developers?
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Here yes it's the macro developer. I'll try to be more specific in
>>>>>>>>> my
>>>>>>>>> answers.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> So if I understand you well, you’re not planning to add a
>>>>>>>>>>
>>>>>>>>> getter/setters to the Macro descriptor, to tell that the macro
>>>>>>>> content
>>>>>>>> contains wiki markup and that it should be editable in the WYSIWYG
>>>>>>>>
>>>>>>> editor?
>>>>>>
>>>>>>>
>>>>>>>>> Actually we're planning to add the getter/setter **and** the
>>>>>>>>> specific
>>>>>>>>> markup for the editor. The getter/setter (which I called the flag
>>>>>>>>> above), is here to specify that the macro will contain inline
>>>>>>>>>
>>>>>>>> editable
>>>>>>
>>>>>>> content in WYSIWYG. The markup will specify *where* exactly is this
>>>>>>>>> content, and what shouldn't be changed.
>>>>>>>>>
>>>>>>>>
>>>>>>>> About that "flag", you seems to plan a boolean but I feel something
>>>>>>>> more generic that we want to introduce since a long time would be
>>>>>>>> better: make the content descriptor return a type like parameters
>>>>>>>> descriptors do. The kind of inline editing you have in mind right
>>>>>>>> now
>>>>>>>> would then be associated to the type List<Block> for example (or
>>>>>>>> CompositeBlock
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> or some another type if we want to differentiate
>>>>>>>> between wiki content modified by the macro and wiki content not
>>>>>>>> modified by the macro
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> We need this differentiation.
>>>>>>>
>>>>>>
>>>>>> Sure but as I said you can differentiate using types too and we need
>>>>>> content types for other use cases so it's a good occasion. Also when
>>>>>> you use the type you can differentiate between wiki content and HTML
>>>>>> content and support inline editing of HTML macro in the same system
>>>>>> for example.
>>>>>>
>>>>>>
>>>>> I'm not against your proposal. It's a bit more work though, to define
>>>>> the
>>>>> types, but I suppose it's worth the effort.
>>>>>
>>>>
>>> It's not much more work, just need to define one type for the current
>>> use case ("final" wiki content). Other types can come later when
>>> implementing support for them.
>>>
>>>
>>>>>
>>>>>
>>>> So if I follow the idea would be to use this type defined for the
>>>> content descriptor to specify the behaviour of the editor: e.g. if the
>>>> content descriptor is defined as an html content, then the html editor
>>>> would be used, if it's defined as an inline content, then it would be an
>>>> editor with limitation to clean html and line returns, etc.
>>>>
>>>> Still it does not change the need to specify which elements of the
>>>> content are editable, right?
>>>>
>>>
>>> Sure but that's the "second step". I only talked about replacing the
>>> flag you defined as the first step by a more generic type :)
>>>
>>>
>>>> Moreover I've the feeling that the parameters are already not supporting
>>>> the different types for edition (e.g. a boolean parameter only shows a
>>>> text input). So wouldn't it be a priority before putting a type on the
>>>> content descriptor itself?
>>>>
>>>
>>> The WYSIWYG does miss a lot of displayers and we need work on that for
>>> sure but:
>>> * you get a checkbox for boolean properties so the type is taken into
>>> account
>>> * having more specific displayers is not a requirement for working on
>>> inline wiki editing
>>>
>>>
>>>>
>>>>>>
>>>>>>>
>>>>>>> ). The other types would be used in other use
>>>>>>>> cases (syntax coloring for scripts, json editor, etc.). The idea of
>>>>>>>> using Java type is to be consistent with parameters and reuse
>>>>>>>> existing
>>>>>>>> the displayers in the macro modal window for example but it can
>>>>>>>> cover
>>>>>>>> this need too.
>>>>>>>>
>>>>>>>>
>>>>>>>>> I guess that if the flag is set and the markup is not present, then
>>>>>>>>>
>>>>>>>> the
>>>>>>
>>>>>>> entire content is considered as editable.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Is that because you want to be finer-grained and have macro
>>>>>>>>>> content
>>>>>>>>>>
>>>>>>>>> which can have parts editable with the WYSIWYG while having other
>>>>>>>>
>>>>>>> parts of
>>>>>>
>>>>>>> the content not editable (for example)?
>>>>>>>>
>>>>>>>>>
>>>>>>>>> It's exactly why yes. On my example, the macro user won't be able
>>>>>>>>> to
>>>>>>>>> change the content of the title.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Technically Macros don’t generate HTML, only XDOM. So in order to
>>>>>>>>>>
>>>>>>>>> make
>>>>>>
>>>>>>> it easier for java macro developers, I’d suggest to introduce some
>>>>>>>> new
>>>>>>>> wrapping Block to indicate this information. We might need something
>>>>>>>> similar for wiki macros too, to make it more reusable and typed.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> I'd need to look more on wrapping block but after a quick overlook
>>>>>>>>> it
>>>>>>>>> seems to make sense indeed.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> About parameters, our idea was to define a new metadata attribute
>>>>>>>>>>>
>>>>>>>>>> and
>>>>>>
>>>>>>> to ask users to use it for specifying the content is editable, such
>>>>>>>> as
>>>>>>>>
>>>>>>> for
>>>>>>
>>>>>>> a parameter named foo:
>>>>>>>>
>>>>>>>>>
>>>>>>>>>>> <span class="editable-content" data-parameter="foo">my foo
>>>>>>>>>>>
>>>>>>>>>> parameter
>>>>>>
>>>>>>> value</span>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>> What’s your idea for editing parameters requiring WYSIWYG? How do
>>>>>>>>>>
>>>>>>>>> you
>>>>>>
>>>>>>> present them in the UI? Do you have any mockup?
>>>>>>>>
>>>>>>>>>
>>>>>>>>> I don't have any mockup right now. FTM I see it like this:
>>>>>>>>>     - when creating the macro, the current text input are improved
>>>>>>>>> with
>>>>>>>>> the CKEditor for the editable content/parameters
>>>>>>>>>     - when editing the macro, you stay in the main editor UI, but
>>>>>>>>> the
>>>>>>>>> content is now editable instead of opening back the macro UI
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> However I don't know right now how the editor would manage cases
>>>>>>>>>>>
>>>>>>>>>> such
>>>>>>
>>>>>>> as:
>>>>>>>>
>>>>>>>>> <span class="editable-content">Some content with <span
>>>>>>>>>>>
>>>>>>>>>> class="editable-content" data-parameter="myparameter">a
>>>>>>>> parameter</span></span>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>>> So:
>>>>>>>>>>>     1. Do you agree on the usage of a class named
>>>>>>>>>>> "editable-content"
>>>>>>>>>>>
>>>>>>>>>> which would be used as a tag to allow inline edition?
>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Small details, there’s already the “contenteditable” notion that
>>>>>>>>>>
>>>>>>>>> exists (see https://developer.mozilla.org/
>>>>>>>> fr/docs/Web/HTML/Attributs_
>>>>>>>> universels/contenteditable) so “editable-content” is quite close.
>>>>>>>> Maybe
>>>>>>>> we should have something more xwiki-specific? or more
>>>>>>>> WYSIWYG-specific?
>>>>>>>> Like “editable-wysiwyg” or “wysiwyg-editable”.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> I'm open to suggestion on this one. "wysiwyg-editable" could be
>>>>>>>>> nice.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> My main comment is what I put above: how do we make it easy for
>>>>>>>>>>
>>>>>>>>> macro
>>>>>>
>>>>>>> developers to specify this information.
>>>>>>>>
>>>>>>>>>
>>>>>>>>>>     2. WDYT about using a data-parameter and this class for inline
>>>>>>>>>>>
>>>>>>>>>> editing of parameters?
>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Before answering that part, I would need to understand what’s the
>>>>>>>>>>
>>>>>>>>> proposal in term of UI.
>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Note that the main use case is for content but it’s nice if you
>>>>>>>>>> can
>>>>>>>>>>
>>>>>>>>> also support parameters. Now, accepting markup in parameters is not
>>>>>>>>
>>>>>>> really
>>>>>>
>>>>>>> a great use case IMO and is usually a design issue so I’m not sure we
>>>>>>>> should spend that much time in supporting that. WDYT?
>>>>>>>>
>>>>>>>>>
>>>>>>>>> We just discuss about macro parameters with Ludovic and apparently
>>>>>>>>>
>>>>>>>> they
>>>>>>
>>>>>>> cannot support line returns, so we might have to use a custom editor
>>>>>>>>>
>>>>>>>> for
>>>>>>
>>>>>>> those.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> The only macro parameter I know ATM that supports markup is the
>>>>>>>>>>
>>>>>>>>> “title” param of the {{box}} macro and I think it’s badly designed.
>>>>>>>>
>>>>>>> Note:
>>>>>>
>>>>>>> if you check the recent {{figure}} macro, I implemented this need by
>>>>>>>>
>>>>>>> having
>>>>>>
>>>>>>> a {{figureCaption}} nested macro.
>>>>>>>>
>>>>>>>>>
>>>>>>>>>> BTW this raises a question, will you support WYSIWYG editing of
>>>>>>>>>>
>>>>>>>>> nested
>>>>>>
>>>>>>> macros?
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Not for the moment.
>>>>>>>>>
>>>>>>>>> Simon
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Thanks
>>>>>>>>>> -Vincent
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>>> Simon
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> [snip]
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Simon Urli
>>>>>>>>> Software Engineer at XWiki SAS
>>>>>>>>> [hidden email]
>>>>>>>>> More about us at http://www.xwiki.com
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Thomas Mortagne
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Thomas Mortagne
>>>>>>
>>>>>>
>>>> --
>>>> Simon Urli
>>>> Software Engineer at XWiki SAS
>>>> [hidden email]
>>>> More about us at http://www.xwiki.com
>>>>
>>>
>>>
>>>
>>>
>> --
>> Simon Urli
>> Software Engineer at XWiki SAS
>> [hidden email]
>> More about us at http://www.xwiki.com
>>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for Macro inline edition

Thomas Mortagne
Administrator
On Wed, Sep 12, 2018 at 5:16 PM Marius Dumitru Florea
<[hidden email]> wrote:

>
> On Wed, Sep 12, 2018 at 6:02 PM, Marius Dumitru Florea <
> [hidden email]> wrote:
>
> > On Wed, Sep 12, 2018 at 5:18 PM, Simon Urli <[hidden email]> wrote:
> >
> >> Hello everyone,
> >>
> >> as a follow up of this proposal and the discussion we had, I just created
> >> the following design proposal:
> >>
> >> https://design.xwiki.org/xwiki/bin/view/Main/MacroInlineEditingContent/
> >>
> >> Let me know what you think about it.
> >>
> >
> > Regarding the Content Descriptor, which Syntax(es) will activate the
> > inline editing of the macro content? I'm asking because the Syntax of the
> > content is not the most important part. The most important part for the
> > WYSIWYG editor is to know if the macro code outputs the macro content
> > without transforming it. Without this it cannot enable inline editing. If
> > the macro output is rendered without modifications then the WYSIWYG editor
> > can enable inline editing but it needs to know in which Syntax to convert
> > the HTML produced while editing inline. So to summarize:
> >
> > * First the WYSIWYG editor needs to know if the macro content is rendered
> > without modifications
> > * then the WYSIWYG editor needs to know the target Syntax to which to
> > convert the HTML
> >
>
> Let me try to make this even more clear.  The WYSIWYG editor needs to take
> the following decisions:
>
> [OPTIONAL] "Should I display the macro content (plain) text area on the
> Macro Edit dialog?"
>
> If the macro content can be edited inline within the editing area then it
> probably make sense to not display the text area on the Macro Edit dialog.
> But for this we need some *static* information in the macro descriptor to
> indicate that the macro content can be edited inline.
>
> [MANDATORY] "Should I enable inline editing for this macro?"
>
> The WYSIWYG editor can scan the macro output DOM (HTML) for some special
> markers (attributes) to determine if the macro content can be edited inline
>


> [MANDATORY] "To which syntax do I need to convert the HTML from the macro
> content?"
>
> When saving the page the editor needs to convert the macro content from
> HTML to some syntax. The target syntax needs to be specified either in the
> macro output DOM (HTML) using some attributes or in the macro descriptor.

That's only if the syntax is different from the current syntax (which
is not the case for most inline edited macros containing wiki
content).

>
> Hope this helps,
> Marius
>
>
> >
> >
> >>
> >> Thanks,
> >> Simon
> >>
> >>
> >> On 9/10/18 6:46 PM, Thomas Mortagne wrote:
> >>
> >>> On Mon, Sep 10, 2018 at 3:47 PM Simon Urli <[hidden email]> wrote:
> >>>
> >>>>
> >>>>
> >>>>
> >>>> On 9/10/18 3:24 PM, Marius Dumitru Florea wrote:
> >>>>
> >>>>> On Mon, Sep 10, 2018 at 4:07 PM, Thomas Mortagne <
> >>>>> [hidden email]>
> >>>>> wrote:
> >>>>>
> >>>>> On Mon, Sep 10, 2018 at 2:56 PM Marius Dumitru Florea
> >>>>>> <[hidden email]> wrote:
> >>>>>>
> >>>>>>>
> >>>>>>> On Mon, Sep 10, 2018 at 3:42 PM, Thomas Mortagne <
> >>>>>>>
> >>>>>> [hidden email]>
> >>>>>>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>> On Mon, Sep 10, 2018 at 2:13 PM Simon Urli <[hidden email]>
> >>>>>>>>
> >>>>>>> wrote:
> >>>>>>
> >>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On 9/10/18 1:35 PM, Vincent Massol wrote:
> >>>>>>>>>
> >>>>>>>>>> Hi Simon,
> >>>>>>>>>>
> >>>>>>>>>> On 10 Sep 2018, at 13:05, Simon Urli <[hidden email]>
> >>>>>>>>>>>
> >>>>>>>>>> wrote:
> >>>>>>
> >>>>>>>
> >>>>>>>>>>> Hi everyone,
> >>>>>>>>>>>
> >>>>>>>>>>> I'm working on the roadmap issues related to the inline edition
> >>>>>>>>>>>
> >>>>>>>>>> with
> >>>>>>
> >>>>>>> WYSIWYG editor for macro content and macro parameters.
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> Cool :) We've been waiting for a long time about this feature! See
> >>>>>>>>>>
> >>>>>>>>> below.
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> The first step is to add a flag to allow user specify that a
> >>>>>>>>>>>
> >>>>>>>>>> content
> >>>>>>
> >>>>>>> or a parameter can be edited inline with the WYSIWYG editor.
> >>>>>>>>
> >>>>>>>>> The second step is to allow the CKEditor to detect where the
> >>>>>>>>>>>
> >>>>>>>>>> content
> >>>>>>
> >>>>>>> and/or parameters should be edited.
> >>>>>>>>
> >>>>>>>>> Let's take the exampe of a simple macro without any parameter,
> >>>>>>>>>>>
> >>>>>>>>>> which
> >>>>>>
> >>>>>>> currently produces this code:
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>> <div class="box infomessage">
> >>>>>>>>>>>     <div class="title">
> >>>>>>>>>>>       <span class="icon info"></span>
> >>>>>>>>>>>       some title
> >>>>>>>>>>>     </div>
> >>>>>>>>>>>     Some content
> >>>>>>>>>>> </div>
> >>>>>>>>>>>
> >>>>>>>>>>> We propose (me & Marius) to ask users to add a wrapper with a
> >>>>>>>>>>>
> >>>>>>>>>> specific class around the content to tell the editor it should
> >>>>>>>> only
> >>>>>>>>
> >>>>>>> allow
> >>>>>>
> >>>>>>> editing this content, e.g.:
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>> <div class="box infomessage">
> >>>>>>>>>>>     <div class="title">
> >>>>>>>>>>>       <span class="icon info"></span>
> >>>>>>>>>>>       some title
> >>>>>>>>>>>     </div>
> >>>>>>>>>>>     <span class="editable-content">Some content</span>
> >>>>>>>>>>> </div>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> By “users”, I guess you mean macro developers?
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Here yes it's the macro developer. I'll try to be more specific in
> >>>>>>>>> my
> >>>>>>>>> answers.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> So if I understand you well, you’re not planning to add a
> >>>>>>>>>>
> >>>>>>>>> getter/setters to the Macro descriptor, to tell that the macro
> >>>>>>>> content
> >>>>>>>> contains wiki markup and that it should be editable in the WYSIWYG
> >>>>>>>>
> >>>>>>> editor?
> >>>>>>
> >>>>>>>
> >>>>>>>>> Actually we're planning to add the getter/setter **and** the
> >>>>>>>>> specific
> >>>>>>>>> markup for the editor. The getter/setter (which I called the flag
> >>>>>>>>> above), is here to specify that the macro will contain inline
> >>>>>>>>>
> >>>>>>>> editable
> >>>>>>
> >>>>>>> content in WYSIWYG. The markup will specify *where* exactly is this
> >>>>>>>>> content, and what shouldn't be changed.
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> About that "flag", you seems to plan a boolean but I feel something
> >>>>>>>> more generic that we want to introduce since a long time would be
> >>>>>>>> better: make the content descriptor return a type like parameters
> >>>>>>>> descriptors do. The kind of inline editing you have in mind right
> >>>>>>>> now
> >>>>>>>> would then be associated to the type List<Block> for example (or
> >>>>>>>> CompositeBlock
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> or some another type if we want to differentiate
> >>>>>>>> between wiki content modified by the macro and wiki content not
> >>>>>>>> modified by the macro
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> We need this differentiation.
> >>>>>>>
> >>>>>>
> >>>>>> Sure but as I said you can differentiate using types too and we need
> >>>>>> content types for other use cases so it's a good occasion. Also when
> >>>>>> you use the type you can differentiate between wiki content and HTML
> >>>>>> content and support inline editing of HTML macro in the same system
> >>>>>> for example.
> >>>>>>
> >>>>>>
> >>>>> I'm not against your proposal. It's a bit more work though, to define
> >>>>> the
> >>>>> types, but I suppose it's worth the effort.
> >>>>>
> >>>>
> >>> It's not much more work, just need to define one type for the current
> >>> use case ("final" wiki content). Other types can come later when
> >>> implementing support for them.
> >>>
> >>>
> >>>>>
> >>>>>
> >>>> So if I follow the idea would be to use this type defined for the
> >>>> content descriptor to specify the behaviour of the editor: e.g. if the
> >>>> content descriptor is defined as an html content, then the html editor
> >>>> would be used, if it's defined as an inline content, then it would be an
> >>>> editor with limitation to clean html and line returns, etc.
> >>>>
> >>>> Still it does not change the need to specify which elements of the
> >>>> content are editable, right?
> >>>>
> >>>
> >>> Sure but that's the "second step". I only talked about replacing the
> >>> flag you defined as the first step by a more generic type :)
> >>>
> >>>
> >>>> Moreover I've the feeling that the parameters are already not supporting
> >>>> the different types for edition (e.g. a boolean parameter only shows a
> >>>> text input). So wouldn't it be a priority before putting a type on the
> >>>> content descriptor itself?
> >>>>
> >>>
> >>> The WYSIWYG does miss a lot of displayers and we need work on that for
> >>> sure but:
> >>> * you get a checkbox for boolean properties so the type is taken into
> >>> account
> >>> * having more specific displayers is not a requirement for working on
> >>> inline wiki editing
> >>>
> >>>
> >>>>
> >>>>>>
> >>>>>>>
> >>>>>>> ). The other types would be used in other use
> >>>>>>>> cases (syntax coloring for scripts, json editor, etc.). The idea of
> >>>>>>>> using Java type is to be consistent with parameters and reuse
> >>>>>>>> existing
> >>>>>>>> the displayers in the macro modal window for example but it can
> >>>>>>>> cover
> >>>>>>>> this need too.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> I guess that if the flag is set and the markup is not present, then
> >>>>>>>>>
> >>>>>>>> the
> >>>>>>
> >>>>>>> entire content is considered as editable.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> Is that because you want to be finer-grained and have macro
> >>>>>>>>>> content
> >>>>>>>>>>
> >>>>>>>>> which can have parts editable with the WYSIWYG while having other
> >>>>>>>>
> >>>>>>> parts of
> >>>>>>
> >>>>>>> the content not editable (for example)?
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> It's exactly why yes. On my example, the macro user won't be able
> >>>>>>>>> to
> >>>>>>>>> change the content of the title.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> Technically Macros don’t generate HTML, only XDOM. So in order to
> >>>>>>>>>>
> >>>>>>>>> make
> >>>>>>
> >>>>>>> it easier for java macro developers, I’d suggest to introduce some
> >>>>>>>> new
> >>>>>>>> wrapping Block to indicate this information. We might need something
> >>>>>>>> similar for wiki macros too, to make it more reusable and typed.
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> I'd need to look more on wrapping block but after a quick overlook
> >>>>>>>>> it
> >>>>>>>>> seems to make sense indeed.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> About parameters, our idea was to define a new metadata attribute
> >>>>>>>>>>>
> >>>>>>>>>> and
> >>>>>>
> >>>>>>> to ask users to use it for specifying the content is editable, such
> >>>>>>>> as
> >>>>>>>>
> >>>>>>> for
> >>>>>>
> >>>>>>> a parameter named foo:
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>> <span class="editable-content" data-parameter="foo">my foo
> >>>>>>>>>>>
> >>>>>>>>>> parameter
> >>>>>>
> >>>>>>> value</span>
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> What’s your idea for editing parameters requiring WYSIWYG? How do
> >>>>>>>>>>
> >>>>>>>>> you
> >>>>>>
> >>>>>>> present them in the UI? Do you have any mockup?
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> I don't have any mockup right now. FTM I see it like this:
> >>>>>>>>>     - when creating the macro, the current text input are improved
> >>>>>>>>> with
> >>>>>>>>> the CKEditor for the editable content/parameters
> >>>>>>>>>     - when editing the macro, you stay in the main editor UI, but
> >>>>>>>>> the
> >>>>>>>>> content is now editable instead of opening back the macro UI
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> However I don't know right now how the editor would manage cases
> >>>>>>>>>>>
> >>>>>>>>>> such
> >>>>>>
> >>>>>>> as:
> >>>>>>>>
> >>>>>>>>> <span class="editable-content">Some content with <span
> >>>>>>>>>>>
> >>>>>>>>>> class="editable-content" data-parameter="myparameter">a
> >>>>>>>> parameter</span></span>
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>> So:
> >>>>>>>>>>>     1. Do you agree on the usage of a class named
> >>>>>>>>>>> "editable-content"
> >>>>>>>>>>>
> >>>>>>>>>> which would be used as a tag to allow inline edition?
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> Small details, there’s already the “contenteditable” notion that
> >>>>>>>>>>
> >>>>>>>>> exists (see https://developer.mozilla.org/
> >>>>>>>> fr/docs/Web/HTML/Attributs_
> >>>>>>>> universels/contenteditable) so “editable-content” is quite close.
> >>>>>>>> Maybe
> >>>>>>>> we should have something more xwiki-specific? or more
> >>>>>>>> WYSIWYG-specific?
> >>>>>>>> Like “editable-wysiwyg” or “wysiwyg-editable”.
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> I'm open to suggestion on this one. "wysiwyg-editable" could be
> >>>>>>>>> nice.
> >>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> My main comment is what I put above: how do we make it easy for
> >>>>>>>>>>
> >>>>>>>>> macro
> >>>>>>
> >>>>>>> developers to specify this information.
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>     2. WDYT about using a data-parameter and this class for inline
> >>>>>>>>>>>
> >>>>>>>>>> editing of parameters?
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> Before answering that part, I would need to understand what’s the
> >>>>>>>>>>
> >>>>>>>>> proposal in term of UI.
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> Note that the main use case is for content but it’s nice if you
> >>>>>>>>>> can
> >>>>>>>>>>
> >>>>>>>>> also support parameters. Now, accepting markup in parameters is not
> >>>>>>>>
> >>>>>>> really
> >>>>>>
> >>>>>>> a great use case IMO and is usually a design issue so I’m not sure we
> >>>>>>>> should spend that much time in supporting that. WDYT?
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> We just discuss about macro parameters with Ludovic and apparently
> >>>>>>>>>
> >>>>>>>> they
> >>>>>>
> >>>>>>> cannot support line returns, so we might have to use a custom editor
> >>>>>>>>>
> >>>>>>>> for
> >>>>>>
> >>>>>>> those.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> The only macro parameter I know ATM that supports markup is the
> >>>>>>>>>>
> >>>>>>>>> “title” param of the {{box}} macro and I think it’s badly designed.
> >>>>>>>>
> >>>>>>> Note:
> >>>>>>
> >>>>>>> if you check the recent {{figure}} macro, I implemented this need by
> >>>>>>>>
> >>>>>>> having
> >>>>>>
> >>>>>>> a {{figureCaption}} nested macro.
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> BTW this raises a question, will you support WYSIWYG editing of
> >>>>>>>>>>
> >>>>>>>>> nested
> >>>>>>
> >>>>>>> macros?
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Not for the moment.
> >>>>>>>>>
> >>>>>>>>> Simon
> >>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Thanks
> >>>>>>>>>> -Vincent
> >>>>>>>>>>
> >>>>>>>>>> Thanks,
> >>>>>>>>>>> Simon
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> [snip]
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>> --
> >>>>>>>>> Simon Urli
> >>>>>>>>> Software Engineer at XWiki SAS
> >>>>>>>>> [hidden email]
> >>>>>>>>> More about us at http://www.xwiki.com
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> --
> >>>>>>>> Thomas Mortagne
> >>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> Thomas Mortagne
> >>>>>>
> >>>>>>
> >>>> --
> >>>> Simon Urli
> >>>> Software Engineer at XWiki SAS
> >>>> [hidden email]
> >>>> More about us at http://www.xwiki.com
> >>>>
> >>>
> >>>
> >>>
> >>>
> >> --
> >> Simon Urli
> >> Software Engineer at XWiki SAS
> >> [hidden email]
> >> More about us at http://www.xwiki.com
> >>
> >
> >



--
Thomas Mortagne
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for Macro inline edition

Marius Dumitru Florea
On Wed, Sep 12, 2018 at 6:20 PM, Thomas Mortagne <[hidden email]>
wrote:

> On Wed, Sep 12, 2018 at 5:16 PM Marius Dumitru Florea
> <[hidden email]> wrote:
> >
> > On Wed, Sep 12, 2018 at 6:02 PM, Marius Dumitru Florea <
> > [hidden email]> wrote:
> >
> > > On Wed, Sep 12, 2018 at 5:18 PM, Simon Urli <[hidden email]>
> wrote:
> > >
> > >> Hello everyone,
> > >>
> > >> as a follow up of this proposal and the discussion we had, I just
> created
> > >> the following design proposal:
> > >>
> > >> https://design.xwiki.org/xwiki/bin/view/Main/
> MacroInlineEditingContent/
> > >>
> > >> Let me know what you think about it.
> > >>
> > >
> > > Regarding the Content Descriptor, which Syntax(es) will activate the
> > > inline editing of the macro content? I'm asking because the Syntax of
> the
> > > content is not the most important part. The most important part for the
> > > WYSIWYG editor is to know if the macro code outputs the macro content
> > > without transforming it. Without this it cannot enable inline editing.
> If
> > > the macro output is rendered without modifications then the WYSIWYG
> editor
> > > can enable inline editing but it needs to know in which Syntax to
> convert
> > > the HTML produced while editing inline. So to summarize:
> > >
> > > * First the WYSIWYG editor needs to know if the macro content is
> rendered
> > > without modifications
> > > * then the WYSIWYG editor needs to know the target Syntax to which to
> > > convert the HTML
> > >
> >
> > Let me try to make this even more clear.  The WYSIWYG editor needs to
> take
> > the following decisions:
> >
> > [OPTIONAL] "Should I display the macro content (plain) text area on the
> > Macro Edit dialog?"
> >
> > If the macro content can be edited inline within the editing area then it
> > probably make sense to not display the text area on the Macro Edit
> dialog.
> > But for this we need some *static* information in the macro descriptor to
> > indicate that the macro content can be edited inline.
> >
> > [MANDATORY] "Should I enable inline editing for this macro?"
> >
> > The WYSIWYG editor can scan the macro output DOM (HTML) for some special
> > markers (attributes) to determine if the macro content can be edited
> inline
> >
>
>
> > [MANDATORY] "To which syntax do I need to convert the HTML from the macro
> > content?"
> >
> > When saving the page the editor needs to convert the macro content from
> > HTML to some syntax. The target syntax needs to be specified either in
> the
> > macro output DOM (HTML) using some attributes or in the macro descriptor.
>
>

> That's only if the syntax is different from the current syntax (which
> is not the case for most inline edited macros containing wiki
> content).
>

Exactly! The macros we target with this feature use the current syntax (of
the page where the macro is called) for their content.


>
> >
> > Hope this helps,
> > Marius
> >
> >
> > >
> > >
> > >>
> > >> Thanks,
> > >> Simon
> > >>
> > >>
> > >> On 9/10/18 6:46 PM, Thomas Mortagne wrote:
> > >>
> > >>> On Mon, Sep 10, 2018 at 3:47 PM Simon Urli <[hidden email]>
> wrote:
> > >>>
> > >>>>
> > >>>>
> > >>>>
> > >>>> On 9/10/18 3:24 PM, Marius Dumitru Florea wrote:
> > >>>>
> > >>>>> On Mon, Sep 10, 2018 at 4:07 PM, Thomas Mortagne <
> > >>>>> [hidden email]>
> > >>>>> wrote:
> > >>>>>
> > >>>>> On Mon, Sep 10, 2018 at 2:56 PM Marius Dumitru Florea
> > >>>>>> <[hidden email]> wrote:
> > >>>>>>
> > >>>>>>>
> > >>>>>>> On Mon, Sep 10, 2018 at 3:42 PM, Thomas Mortagne <
> > >>>>>>>
> > >>>>>> [hidden email]>
> > >>>>>>
> > >>>>>>> wrote:
> > >>>>>>>
> > >>>>>>> On Mon, Sep 10, 2018 at 2:13 PM Simon Urli <[hidden email]
> >
> > >>>>>>>>
> > >>>>>>> wrote:
> > >>>>>>
> > >>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>> On 9/10/18 1:35 PM, Vincent Massol wrote:
> > >>>>>>>>>
> > >>>>>>>>>> Hi Simon,
> > >>>>>>>>>>
> > >>>>>>>>>> On 10 Sep 2018, at 13:05, Simon Urli <[hidden email]>
> > >>>>>>>>>>>
> > >>>>>>>>>> wrote:
> > >>>>>>
> > >>>>>>>
> > >>>>>>>>>>> Hi everyone,
> > >>>>>>>>>>>
> > >>>>>>>>>>> I'm working on the roadmap issues related to the inline
> edition
> > >>>>>>>>>>>
> > >>>>>>>>>> with
> > >>>>>>
> > >>>>>>> WYSIWYG editor for macro content and macro parameters.
> > >>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>> Cool :) We've been waiting for a long time about this
> feature! See
> > >>>>>>>>>>
> > >>>>>>>>> below.
> > >>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>> The first step is to add a flag to allow user specify that a
> > >>>>>>>>>>>
> > >>>>>>>>>> content
> > >>>>>>
> > >>>>>>> or a parameter can be edited inline with the WYSIWYG editor.
> > >>>>>>>>
> > >>>>>>>>> The second step is to allow the CKEditor to detect where the
> > >>>>>>>>>>>
> > >>>>>>>>>> content
> > >>>>>>
> > >>>>>>> and/or parameters should be edited.
> > >>>>>>>>
> > >>>>>>>>> Let's take the exampe of a simple macro without any parameter,
> > >>>>>>>>>>>
> > >>>>>>>>>> which
> > >>>>>>
> > >>>>>>> currently produces this code:
> > >>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>>> <div class="box infomessage">
> > >>>>>>>>>>>     <div class="title">
> > >>>>>>>>>>>       <span class="icon info"></span>
> > >>>>>>>>>>>       some title
> > >>>>>>>>>>>     </div>
> > >>>>>>>>>>>     Some content
> > >>>>>>>>>>> </div>
> > >>>>>>>>>>>
> > >>>>>>>>>>> We propose (me & Marius) to ask users to add a wrapper with a
> > >>>>>>>>>>>
> > >>>>>>>>>> specific class around the content to tell the editor it should
> > >>>>>>>> only
> > >>>>>>>>
> > >>>>>>> allow
> > >>>>>>
> > >>>>>>> editing this content, e.g.:
> > >>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>>> <div class="box infomessage">
> > >>>>>>>>>>>     <div class="title">
> > >>>>>>>>>>>       <span class="icon info"></span>
> > >>>>>>>>>>>       some title
> > >>>>>>>>>>>     </div>
> > >>>>>>>>>>>     <span class="editable-content">Some content</span>
> > >>>>>>>>>>> </div>
> > >>>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>> By “users”, I guess you mean macro developers?
> > >>>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>> Here yes it's the macro developer. I'll try to be more
> specific in
> > >>>>>>>>> my
> > >>>>>>>>> answers.
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>> So if I understand you well, you’re not planning to add a
> > >>>>>>>>>>
> > >>>>>>>>> getter/setters to the Macro descriptor, to tell that the macro
> > >>>>>>>> content
> > >>>>>>>> contains wiki markup and that it should be editable in the
> WYSIWYG
> > >>>>>>>>
> > >>>>>>> editor?
> > >>>>>>
> > >>>>>>>
> > >>>>>>>>> Actually we're planning to add the getter/setter **and** the
> > >>>>>>>>> specific
> > >>>>>>>>> markup for the editor. The getter/setter (which I called the
> flag
> > >>>>>>>>> above), is here to specify that the macro will contain inline
> > >>>>>>>>>
> > >>>>>>>> editable
> > >>>>>>
> > >>>>>>> content in WYSIWYG. The markup will specify *where* exactly is
> this
> > >>>>>>>>> content, and what shouldn't be changed.
> > >>>>>>>>>
> > >>>>>>>>
> > >>>>>>>> About that "flag", you seems to plan a boolean but I feel
> something
> > >>>>>>>> more generic that we want to introduce since a long time would
> be
> > >>>>>>>> better: make the content descriptor return a type like
> parameters
> > >>>>>>>> descriptors do. The kind of inline editing you have in mind
> right
> > >>>>>>>> now
> > >>>>>>>> would then be associated to the type List<Block> for example (or
> > >>>>>>>> CompositeBlock
> > >>>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> or some another type if we want to differentiate
> > >>>>>>>> between wiki content modified by the macro and wiki content not
> > >>>>>>>> modified by the macro
> > >>>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> We need this differentiation.
> > >>>>>>>
> > >>>>>>
> > >>>>>> Sure but as I said you can differentiate using types too and we
> need
> > >>>>>> content types for other use cases so it's a good occasion. Also
> when
> > >>>>>> you use the type you can differentiate between wiki content and
> HTML
> > >>>>>> content and support inline editing of HTML macro in the same
> system
> > >>>>>> for example.
> > >>>>>>
> > >>>>>>
> > >>>>> I'm not against your proposal. It's a bit more work though, to
> define
> > >>>>> the
> > >>>>> types, but I suppose it's worth the effort.
> > >>>>>
> > >>>>
> > >>> It's not much more work, just need to define one type for the current
> > >>> use case ("final" wiki content). Other types can come later when
> > >>> implementing support for them.
> > >>>
> > >>>
> > >>>>>
> > >>>>>
> > >>>> So if I follow the idea would be to use this type defined for the
> > >>>> content descriptor to specify the behaviour of the editor: e.g. if
> the
> > >>>> content descriptor is defined as an html content, then the html
> editor
> > >>>> would be used, if it's defined as an inline content, then it would
> be an
> > >>>> editor with limitation to clean html and line returns, etc.
> > >>>>
> > >>>> Still it does not change the need to specify which elements of the
> > >>>> content are editable, right?
> > >>>>
> > >>>
> > >>> Sure but that's the "second step". I only talked about replacing the
> > >>> flag you defined as the first step by a more generic type :)
> > >>>
> > >>>
> > >>>> Moreover I've the feeling that the parameters are already not
> supporting
> > >>>> the different types for edition (e.g. a boolean parameter only
> shows a
> > >>>> text input). So wouldn't it be a priority before putting a type on
> the
> > >>>> content descriptor itself?
> > >>>>
> > >>>
> > >>> The WYSIWYG does miss a lot of displayers and we need work on that
> for
> > >>> sure but:
> > >>> * you get a checkbox for boolean properties so the type is taken into
> > >>> account
> > >>> * having more specific displayers is not a requirement for working on
> > >>> inline wiki editing
> > >>>
> > >>>
> > >>>>
> > >>>>>>
> > >>>>>>>
> > >>>>>>> ). The other types would be used in other use
> > >>>>>>>> cases (syntax coloring for scripts, json editor, etc.). The
> idea of
> > >>>>>>>> using Java type is to be consistent with parameters and reuse
> > >>>>>>>> existing
> > >>>>>>>> the displayers in the macro modal window for example but it can
> > >>>>>>>> cover
> > >>>>>>>> this need too.
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>> I guess that if the flag is set and the markup is not present,
> then
> > >>>>>>>>>
> > >>>>>>>> the
> > >>>>>>
> > >>>>>>> entire content is considered as editable.
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>> Is that because you want to be finer-grained and have macro
> > >>>>>>>>>> content
> > >>>>>>>>>>
> > >>>>>>>>> which can have parts editable with the WYSIWYG while having
> other
> > >>>>>>>>
> > >>>>>>> parts of
> > >>>>>>
> > >>>>>>> the content not editable (for example)?
> > >>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>> It's exactly why yes. On my example, the macro user won't be
> able
> > >>>>>>>>> to
> > >>>>>>>>> change the content of the title.
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>> Technically Macros don’t generate HTML, only XDOM. So in
> order to
> > >>>>>>>>>>
> > >>>>>>>>> make
> > >>>>>>
> > >>>>>>> it easier for java macro developers, I’d suggest to introduce
> some
> > >>>>>>>> new
> > >>>>>>>> wrapping Block to indicate this information. We might need
> something
> > >>>>>>>> similar for wiki macros too, to make it more reusable and typed.
> > >>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>> I'd need to look more on wrapping block but after a quick
> overlook
> > >>>>>>>>> it
> > >>>>>>>>> seems to make sense indeed.
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>> About parameters, our idea was to define a new metadata
> attribute
> > >>>>>>>>>>>
> > >>>>>>>>>> and
> > >>>>>>
> > >>>>>>> to ask users to use it for specifying the content is editable,
> such
> > >>>>>>>> as
> > >>>>>>>>
> > >>>>>>> for
> > >>>>>>
> > >>>>>>> a parameter named foo:
> > >>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>>> <span class="editable-content" data-parameter="foo">my foo
> > >>>>>>>>>>>
> > >>>>>>>>>> parameter
> > >>>>>>
> > >>>>>>> value</span>
> > >>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>> What’s your idea for editing parameters requiring WYSIWYG?
> How do
> > >>>>>>>>>>
> > >>>>>>>>> you
> > >>>>>>
> > >>>>>>> present them in the UI? Do you have any mockup?
> > >>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>> I don't have any mockup right now. FTM I see it like this:
> > >>>>>>>>>     - when creating the macro, the current text input are
> improved
> > >>>>>>>>> with
> > >>>>>>>>> the CKEditor for the editable content/parameters
> > >>>>>>>>>     - when editing the macro, you stay in the main editor UI,
> but
> > >>>>>>>>> the
> > >>>>>>>>> content is now editable instead of opening back the macro UI
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>> However I don't know right now how the editor would manage
> cases
> > >>>>>>>>>>>
> > >>>>>>>>>> such
> > >>>>>>
> > >>>>>>> as:
> > >>>>>>>>
> > >>>>>>>>> <span class="editable-content">Some content with <span
> > >>>>>>>>>>>
> > >>>>>>>>>> class="editable-content" data-parameter="myparameter">a
> > >>>>>>>> parameter</span></span>
> > >>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>>> So:
> > >>>>>>>>>>>     1. Do you agree on the usage of a class named
> > >>>>>>>>>>> "editable-content"
> > >>>>>>>>>>>
> > >>>>>>>>>> which would be used as a tag to allow inline edition?
> > >>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>> Small details, there’s already the “contenteditable” notion
> that
> > >>>>>>>>>>
> > >>>>>>>>> exists (see https://developer.mozilla.org/
> > >>>>>>>> fr/docs/Web/HTML/Attributs_
> > >>>>>>>> universels/contenteditable) so “editable-content” is quite
> close.
> > >>>>>>>> Maybe
> > >>>>>>>> we should have something more xwiki-specific? or more
> > >>>>>>>> WYSIWYG-specific?
> > >>>>>>>> Like “editable-wysiwyg” or “wysiwyg-editable”.
> > >>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>> I'm open to suggestion on this one. "wysiwyg-editable" could be
> > >>>>>>>>> nice.
> > >>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>> My main comment is what I put above: how do we make it easy
> for
> > >>>>>>>>>>
> > >>>>>>>>> macro
> > >>>>>>
> > >>>>>>> developers to specify this information.
> > >>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>>     2. WDYT about using a data-parameter and this class for
> inline
> > >>>>>>>>>>>
> > >>>>>>>>>> editing of parameters?
> > >>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>> Before answering that part, I would need to understand what’s
> the
> > >>>>>>>>>>
> > >>>>>>>>> proposal in term of UI.
> > >>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>> Note that the main use case is for content but it’s nice if
> you
> > >>>>>>>>>> can
> > >>>>>>>>>>
> > >>>>>>>>> also support parameters. Now, accepting markup in parameters
> is not
> > >>>>>>>>
> > >>>>>>> really
> > >>>>>>
> > >>>>>>> a great use case IMO and is usually a design issue so I’m not
> sure we
> > >>>>>>>> should spend that much time in supporting that. WDYT?
> > >>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>> We just discuss about macro parameters with Ludovic and
> apparently
> > >>>>>>>>>
> > >>>>>>>> they
> > >>>>>>
> > >>>>>>> cannot support line returns, so we might have to use a custom
> editor
> > >>>>>>>>>
> > >>>>>>>> for
> > >>>>>>
> > >>>>>>> those.
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>> The only macro parameter I know ATM that supports markup is
> the
> > >>>>>>>>>>
> > >>>>>>>>> “title” param of the {{box}} macro and I think it’s badly
> designed.
> > >>>>>>>>
> > >>>>>>> Note:
> > >>>>>>
> > >>>>>>> if you check the recent {{figure}} macro, I implemented this
> need by
> > >>>>>>>>
> > >>>>>>> having
> > >>>>>>
> > >>>>>>> a {{figureCaption}} nested macro.
> > >>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>> BTW this raises a question, will you support WYSIWYG editing
> of
> > >>>>>>>>>>
> > >>>>>>>>> nested
> > >>>>>>
> > >>>>>>> macros?
> > >>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>> Not for the moment.
> > >>>>>>>>>
> > >>>>>>>>> Simon
> > >>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>> Thanks
> > >>>>>>>>>> -Vincent
> > >>>>>>>>>>
> > >>>>>>>>>> Thanks,
> > >>>>>>>>>>> Simon
> > >>>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>> [snip]
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>> --
> > >>>>>>>>> Simon Urli
> > >>>>>>>>> Software Engineer at XWiki SAS
> > >>>>>>>>> [hidden email]
> > >>>>>>>>> More about us at http://www.xwiki.com
> > >>>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>> --
> > >>>>>>>> Thomas Mortagne
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>> --
> > >>>>>> Thomas Mortagne
> > >>>>>>
> > >>>>>>
> > >>>> --
> > >>>> Simon Urli
> > >>>> Software Engineer at XWiki SAS
> > >>>> [hidden email]
> > >>>> More about us at http://www.xwiki.com
> > >>>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >> --
> > >> Simon Urli
> > >> Software Engineer at XWiki SAS
> > >> [hidden email]
> > >> More about us at http://www.xwiki.com
> > >>
> > >
> > >
>
>
>
> --
> Thomas Mortagne
>
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for Macro inline edition

Thomas Mortagne
Administrator
In reply to this post by Simon Urli
On Wed, Sep 12, 2018 at 5:07 PM Simon Urli <[hidden email]> wrote:

>
>
>
> On 9/12/18 5:02 PM, Marius Dumitru Florea wrote:
> > On Wed, Sep 12, 2018 at 5:18 PM, Simon Urli <[hidden email]> wrote:
> >
> >> Hello everyone,
> >>
> >> as a follow up of this proposal and the discussion we had, I just created
> >> the following design proposal:
> >>
> >> https://design.xwiki.org/xwiki/bin/view/Main/MacroInlineEditingContent/
> >>
> >> Let me know what you think about it.
> >>
> >
> > Regarding the Content Descriptor, which Syntax(es) will activate the inline
> > editing of the macro content? I'm asking because the Syntax of the content
> > is not the most important part. The most important part for the WYSIWYG
> > editor is to know if the macro code outputs the macro content without
> > transforming it. Without this it cannot enable inline editing. If the macro
> > output is rendered without modifications then the WYSIWYG editor can enable
> > inline editing but it needs to know in which Syntax to convert the HTML
> > produced while editing inline. So to summarize:
> >
> > * First the WYSIWYG editor needs to know if the macro content is rendered
> > without modifications
> > * then the WYSIWYG editor needs to know the target Syntax to which to
> > convert the HTML
> >
>
> The WYSIWYG editor will know if it's editable if it exists a parser and
> a renderer for this syntax.

You are mixing different things here:
* a macro which can be edited with A WYSIWYG for example in the model macro form
* a macro content which IS NOT TRANSFORMED BY THE MACRO and so can be
edited inline

> So the target syntax is the given macro syntax.
>
> >
> >>
> >> Thanks,
> >> Simon
> >>
> >>
> >> On 9/10/18 6:46 PM, Thomas Mortagne wrote:
> >>
> >>> On Mon, Sep 10, 2018 at 3:47 PM Simon Urli <[hidden email]> wrote:
> >>>
> >>>>
> >>>>
> >>>>
> >>>> On 9/10/18 3:24 PM, Marius Dumitru Florea wrote:
> >>>>
> >>>>> On Mon, Sep 10, 2018 at 4:07 PM, Thomas Mortagne <
> >>>>> [hidden email]>
> >>>>> wrote:
> >>>>>
> >>>>> On Mon, Sep 10, 2018 at 2:56 PM Marius Dumitru Florea
> >>>>>> <[hidden email]> wrote:
> >>>>>>
> >>>>>>>
> >>>>>>> On Mon, Sep 10, 2018 at 3:42 PM, Thomas Mortagne <
> >>>>>>>
> >>>>>> [hidden email]>
> >>>>>>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>> On Mon, Sep 10, 2018 at 2:13 PM Simon Urli <[hidden email]>
> >>>>>>>>
> >>>>>>> wrote:
> >>>>>>
> >>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On 9/10/18 1:35 PM, Vincent Massol wrote:
> >>>>>>>>>
> >>>>>>>>>> Hi Simon,
> >>>>>>>>>>
> >>>>>>>>>> On 10 Sep 2018, at 13:05, Simon Urli <[hidden email]>
> >>>>>>>>>>>
> >>>>>>>>>> wrote:
> >>>>>>
> >>>>>>>
> >>>>>>>>>>> Hi everyone,
> >>>>>>>>>>>
> >>>>>>>>>>> I'm working on the roadmap issues related to the inline edition
> >>>>>>>>>>>
> >>>>>>>>>> with
> >>>>>>
> >>>>>>> WYSIWYG editor for macro content and macro parameters.
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> Cool :) We've been waiting for a long time about this feature! See
> >>>>>>>>>>
> >>>>>>>>> below.
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> The first step is to add a flag to allow user specify that a
> >>>>>>>>>>>
> >>>>>>>>>> content
> >>>>>>
> >>>>>>> or a parameter can be edited inline with the WYSIWYG editor.
> >>>>>>>>
> >>>>>>>>> The second step is to allow the CKEditor to detect where the
> >>>>>>>>>>>
> >>>>>>>>>> content
> >>>>>>
> >>>>>>> and/or parameters should be edited.
> >>>>>>>>
> >>>>>>>>> Let's take the exampe of a simple macro without any parameter,
> >>>>>>>>>>>
> >>>>>>>>>> which
> >>>>>>
> >>>>>>> currently produces this code:
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>> <div class="box infomessage">
> >>>>>>>>>>>      <div class="title">
> >>>>>>>>>>>        <span class="icon info"></span>
> >>>>>>>>>>>        some title
> >>>>>>>>>>>      </div>
> >>>>>>>>>>>      Some content
> >>>>>>>>>>> </div>
> >>>>>>>>>>>
> >>>>>>>>>>> We propose (me & Marius) to ask users to add a wrapper with a
> >>>>>>>>>>>
> >>>>>>>>>> specific class around the content to tell the editor it should only
> >>>>>>>>
> >>>>>>> allow
> >>>>>>
> >>>>>>> editing this content, e.g.:
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>> <div class="box infomessage">
> >>>>>>>>>>>      <div class="title">
> >>>>>>>>>>>        <span class="icon info"></span>
> >>>>>>>>>>>        some title
> >>>>>>>>>>>      </div>
> >>>>>>>>>>>      <span class="editable-content">Some content</span>
> >>>>>>>>>>> </div>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> By “users”, I guess you mean macro developers?
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Here yes it's the macro developer. I'll try to be more specific in
> >>>>>>>>> my
> >>>>>>>>> answers.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> So if I understand you well, you’re not planning to add a
> >>>>>>>>>>
> >>>>>>>>> getter/setters to the Macro descriptor, to tell that the macro
> >>>>>>>> content
> >>>>>>>> contains wiki markup and that it should be editable in the WYSIWYG
> >>>>>>>>
> >>>>>>> editor?
> >>>>>>
> >>>>>>>
> >>>>>>>>> Actually we're planning to add the getter/setter **and** the
> >>>>>>>>> specific
> >>>>>>>>> markup for the editor. The getter/setter (which I called the flag
> >>>>>>>>> above), is here to specify that the macro will contain inline
> >>>>>>>>>
> >>>>>>>> editable
> >>>>>>
> >>>>>>> content in WYSIWYG. The markup will specify *where* exactly is this
> >>>>>>>>> content, and what shouldn't be changed.
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> About that "flag", you seems to plan a boolean but I feel something
> >>>>>>>> more generic that we want to introduce since a long time would be
> >>>>>>>> better: make the content descriptor return a type like parameters
> >>>>>>>> descriptors do. The kind of inline editing you have in mind right now
> >>>>>>>> would then be associated to the type List<Block> for example (or
> >>>>>>>> CompositeBlock
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> or some another type if we want to differentiate
> >>>>>>>> between wiki content modified by the macro and wiki content not
> >>>>>>>> modified by the macro
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> We need this differentiation.
> >>>>>>>
> >>>>>>
> >>>>>> Sure but as I said you can differentiate using types too and we need
> >>>>>> content types for other use cases so it's a good occasion. Also when
> >>>>>> you use the type you can differentiate between wiki content and HTML
> >>>>>> content and support inline editing of HTML macro in the same system
> >>>>>> for example.
> >>>>>>
> >>>>>>
> >>>>> I'm not against your proposal. It's a bit more work though, to define
> >>>>> the
> >>>>> types, but I suppose it's worth the effort.
> >>>>>
> >>>>
> >>> It's not much more work, just need to define one type for the current
> >>> use case ("final" wiki content). Other types can come later when
> >>> implementing support for them.
> >>>
> >>>
> >>>>>
> >>>>>
> >>>> So if I follow the idea would be to use this type defined for the
> >>>> content descriptor to specify the behaviour of the editor: e.g. if the
> >>>> content descriptor is defined as an html content, then the html editor
> >>>> would be used, if it's defined as an inline content, then it would be an
> >>>> editor with limitation to clean html and line returns, etc.
> >>>>
> >>>> Still it does not change the need to specify which elements of the
> >>>> content are editable, right?
> >>>>
> >>>
> >>> Sure but that's the "second step". I only talked about replacing the
> >>> flag you defined as the first step by a more generic type :)
> >>>
> >>>
> >>>> Moreover I've the feeling that the parameters are already not supporting
> >>>> the different types for edition (e.g. a boolean parameter only shows a
> >>>> text input). So wouldn't it be a priority before putting a type on the
> >>>> content descriptor itself?
> >>>>
> >>>
> >>> The WYSIWYG does miss a lot of displayers and we need work on that for
> >>> sure but:
> >>> * you get a checkbox for boolean properties so the type is taken into
> >>> account
> >>> * having more specific displayers is not a requirement for working on
> >>> inline wiki editing
> >>>
> >>>
> >>>>
> >>>>>>
> >>>>>>>
> >>>>>>> ). The other types would be used in other use
> >>>>>>>> cases (syntax coloring for scripts, json editor, etc.). The idea of
> >>>>>>>> using Java type is to be consistent with parameters and reuse
> >>>>>>>> existing
> >>>>>>>> the displayers in the macro modal window for example but it can cover
> >>>>>>>> this need too.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> I guess that if the flag is set and the markup is not present, then
> >>>>>>>>>
> >>>>>>>> the
> >>>>>>
> >>>>>>> entire content is considered as editable.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> Is that because you want to be finer-grained and have macro content
> >>>>>>>>>>
> >>>>>>>>> which can have parts editable with the WYSIWYG while having other
> >>>>>>>>
> >>>>>>> parts of
> >>>>>>
> >>>>>>> the content not editable (for example)?
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> It's exactly why yes. On my example, the macro user won't be able to
> >>>>>>>>> change the content of the title.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> Technically Macros don’t generate HTML, only XDOM. So in order to
> >>>>>>>>>>
> >>>>>>>>> make
> >>>>>>
> >>>>>>> it easier for java macro developers, I’d suggest to introduce some new
> >>>>>>>> wrapping Block to indicate this information. We might need something
> >>>>>>>> similar for wiki macros too, to make it more reusable and typed.
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> I'd need to look more on wrapping block but after a quick overlook
> >>>>>>>>> it
> >>>>>>>>> seems to make sense indeed.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> About parameters, our idea was to define a new metadata attribute
> >>>>>>>>>>>
> >>>>>>>>>> and
> >>>>>>
> >>>>>>> to ask users to use it for specifying the content is editable, such as
> >>>>>>>>
> >>>>>>> for
> >>>>>>
> >>>>>>> a parameter named foo:
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>> <span class="editable-content" data-parameter="foo">my foo
> >>>>>>>>>>>
> >>>>>>>>>> parameter
> >>>>>>
> >>>>>>> value</span>
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> What’s your idea for editing parameters requiring WYSIWYG? How do
> >>>>>>>>>>
> >>>>>>>>> you
> >>>>>>
> >>>>>>> present them in the UI? Do you have any mockup?
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> I don't have any mockup right now. FTM I see it like this:
> >>>>>>>>>      - when creating the macro, the current text input are improved
> >>>>>>>>> with
> >>>>>>>>> the CKEditor for the editable content/parameters
> >>>>>>>>>      - when editing the macro, you stay in the main editor UI, but
> >>>>>>>>> the
> >>>>>>>>> content is now editable instead of opening back the macro UI
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> However I don't know right now how the editor would manage cases
> >>>>>>>>>>>
> >>>>>>>>>> such
> >>>>>>
> >>>>>>> as:
> >>>>>>>>
> >>>>>>>>> <span class="editable-content">Some content with <span
> >>>>>>>>>>>
> >>>>>>>>>> class="editable-content" data-parameter="myparameter">a
> >>>>>>>> parameter</span></span>
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>> So:
> >>>>>>>>>>>      1. Do you agree on the usage of a class named
> >>>>>>>>>>> "editable-content"
> >>>>>>>>>>>
> >>>>>>>>>> which would be used as a tag to allow inline edition?
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> Small details, there’s already the “contenteditable” notion that
> >>>>>>>>>>
> >>>>>>>>> exists (see https://developer.mozilla.org/
> >>>>>>>> fr/docs/Web/HTML/Attributs_
> >>>>>>>> universels/contenteditable) so “editable-content” is quite close.
> >>>>>>>> Maybe
> >>>>>>>> we should have something more xwiki-specific? or more
> >>>>>>>> WYSIWYG-specific?
> >>>>>>>> Like “editable-wysiwyg” or “wysiwyg-editable”.
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> I'm open to suggestion on this one. "wysiwyg-editable" could be
> >>>>>>>>> nice.
> >>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> My main comment is what I put above: how do we make it easy for
> >>>>>>>>>>
> >>>>>>>>> macro
> >>>>>>
> >>>>>>> developers to specify this information.
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>      2. WDYT about using a data-parameter and this class for inline
> >>>>>>>>>>>
> >>>>>>>>>> editing of parameters?
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> Before answering that part, I would need to understand what’s the
> >>>>>>>>>>
> >>>>>>>>> proposal in term of UI.
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> Note that the main use case is for content but it’s nice if you can
> >>>>>>>>>>
> >>>>>>>>> also support parameters. Now, accepting markup in parameters is not
> >>>>>>>>
> >>>>>>> really
> >>>>>>
> >>>>>>> a great use case IMO and is usually a design issue so I’m not sure we
> >>>>>>>> should spend that much time in supporting that. WDYT?
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> We just discuss about macro parameters with Ludovic and apparently
> >>>>>>>>>
> >>>>>>>> they
> >>>>>>
> >>>>>>> cannot support line returns, so we might have to use a custom editor
> >>>>>>>>>
> >>>>>>>> for
> >>>>>>
> >>>>>>> those.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> The only macro parameter I know ATM that supports markup is the
> >>>>>>>>>>
> >>>>>>>>> “title” param of the {{box}} macro and I think it’s badly designed.
> >>>>>>>>
> >>>>>>> Note:
> >>>>>>
> >>>>>>> if you check the recent {{figure}} macro, I implemented this need by
> >>>>>>>>
> >>>>>>> having
> >>>>>>
> >>>>>>> a {{figureCaption}} nested macro.
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> BTW this raises a question, will you support WYSIWYG editing of
> >>>>>>>>>>
> >>>>>>>>> nested
> >>>>>>
> >>>>>>> macros?
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Not for the moment.
> >>>>>>>>>
> >>>>>>>>> Simon
> >>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Thanks
> >>>>>>>>>> -Vincent
> >>>>>>>>>>
> >>>>>>>>>> Thanks,
> >>>>>>>>>>> Simon
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> [snip]
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>> --
> >>>>>>>>> Simon Urli
> >>>>>>>>> Software Engineer at XWiki SAS
> >>>>>>>>> [hidden email]
> >>>>>>>>> More about us at http://www.xwiki.com
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> --
> >>>>>>>> Thomas Mortagne
> >>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> Thomas Mortagne
> >>>>>>
> >>>>>>
> >>>> --
> >>>> Simon Urli
> >>>> Software Engineer at XWiki SAS
> >>>> [hidden email]
> >>>> More about us at http://www.xwiki.com
> >>>>
> >>>
> >>>
> >>>
> >>>
> >> --
> >> Simon Urli
> >> Software Engineer at XWiki SAS
> >> [hidden email]
> >> More about us at http://www.xwiki.com
> >>
>
> --
> Simon Urli
> Software Engineer at XWiki SAS
> [hidden email]
> More about us at http://www.xwiki.com



--
Thomas Mortagne
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for Macro inline edition

Thomas Mortagne
Administrator
In reply to this post by Marius Dumitru Florea
On Wed, Sep 12, 2018 at 5:27 PM Marius Dumitru Florea
<[hidden email]> wrote:

>
> On Wed, Sep 12, 2018 at 6:20 PM, Thomas Mortagne <[hidden email]>
> wrote:
>
> > On Wed, Sep 12, 2018 at 5:16 PM Marius Dumitru Florea
> > <[hidden email]> wrote:
> > >
> > > On Wed, Sep 12, 2018 at 6:02 PM, Marius Dumitru Florea <
> > > [hidden email]> wrote:
> > >
> > > > On Wed, Sep 12, 2018 at 5:18 PM, Simon Urli <[hidden email]>
> > wrote:
> > > >
> > > >> Hello everyone,
> > > >>
> > > >> as a follow up of this proposal and the discussion we had, I just
> > created
> > > >> the following design proposal:
> > > >>
> > > >> https://design.xwiki.org/xwiki/bin/view/Main/
> > MacroInlineEditingContent/
> > > >>
> > > >> Let me know what you think about it.
> > > >>
> > > >
> > > > Regarding the Content Descriptor, which Syntax(es) will activate the
> > > > inline editing of the macro content? I'm asking because the Syntax of
> > the
> > > > content is not the most important part. The most important part for the
> > > > WYSIWYG editor is to know if the macro code outputs the macro content
> > > > without transforming it. Without this it cannot enable inline editing.
> > If
> > > > the macro output is rendered without modifications then the WYSIWYG
> > editor
> > > > can enable inline editing but it needs to know in which Syntax to
> > convert
> > > > the HTML produced while editing inline. So to summarize:
> > > >
> > > > * First the WYSIWYG editor needs to know if the macro content is
> > rendered
> > > > without modifications
> > > > * then the WYSIWYG editor needs to know the target Syntax to which to
> > > > convert the HTML
> > > >
> > >
> > > Let me try to make this even more clear.  The WYSIWYG editor needs to
> > take
> > > the following decisions:
> > >
> > > [OPTIONAL] "Should I display the macro content (plain) text area on the
> > > Macro Edit dialog?"
> > >
> > > If the macro content can be edited inline within the editing area then it
> > > probably make sense to not display the text area on the Macro Edit
> > dialog.
> > > But for this we need some *static* information in the macro descriptor to
> > > indicate that the macro content can be edited inline.
> > >
> > > [MANDATORY] "Should I enable inline editing for this macro?"
> > >
> > > The WYSIWYG editor can scan the macro output DOM (HTML) for some special
> > > markers (attributes) to determine if the macro content can be edited
> > inline
> > >
> >
> >
> > > [MANDATORY] "To which syntax do I need to convert the HTML from the macro
> > > content?"
> > >
> > > When saving the page the editor needs to convert the macro content from
> > > HTML to some syntax. The target syntax needs to be specified either in
> > the
> > > macro output DOM (HTML) using some attributes or in the macro descriptor.
> >
> >
>
> > That's only if the syntax is different from the current syntax (which
> > is not the case for most inline edited macros containing wiki
> > content).
> >
>
> Exactly! The macros we target with this feature use the current syntax (of
> the page where the macro is called) for their content.

My point is that the WYSIWYG know the syntax already you don't need
each macro to provide it as metadata.

>
>
> >
> > >
> > > Hope this helps,
> > > Marius
> > >
> > >
> > > >
> > > >
> > > >>
> > > >> Thanks,
> > > >> Simon
> > > >>
> > > >>
> > > >> On 9/10/18 6:46 PM, Thomas Mortagne wrote:
> > > >>
> > > >>> On Mon, Sep 10, 2018 at 3:47 PM Simon Urli <[hidden email]>
> > wrote:
> > > >>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>> On 9/10/18 3:24 PM, Marius Dumitru Florea wrote:
> > > >>>>
> > > >>>>> On Mon, Sep 10, 2018 at 4:07 PM, Thomas Mortagne <
> > > >>>>> [hidden email]>
> > > >>>>> wrote:
> > > >>>>>
> > > >>>>> On Mon, Sep 10, 2018 at 2:56 PM Marius Dumitru Florea
> > > >>>>>> <[hidden email]> wrote:
> > > >>>>>>
> > > >>>>>>>
> > > >>>>>>> On Mon, Sep 10, 2018 at 3:42 PM, Thomas Mortagne <
> > > >>>>>>>
> > > >>>>>> [hidden email]>
> > > >>>>>>
> > > >>>>>>> wrote:
> > > >>>>>>>
> > > >>>>>>> On Mon, Sep 10, 2018 at 2:13 PM Simon Urli <[hidden email]
> > >
> > > >>>>>>>>
> > > >>>>>>> wrote:
> > > >>>>>>
> > > >>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>> On 9/10/18 1:35 PM, Vincent Massol wrote:
> > > >>>>>>>>>
> > > >>>>>>>>>> Hi Simon,
> > > >>>>>>>>>>
> > > >>>>>>>>>> On 10 Sep 2018, at 13:05, Simon Urli <[hidden email]>
> > > >>>>>>>>>>>
> > > >>>>>>>>>> wrote:
> > > >>>>>>
> > > >>>>>>>
> > > >>>>>>>>>>> Hi everyone,
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> I'm working on the roadmap issues related to the inline
> > edition
> > > >>>>>>>>>>>
> > > >>>>>>>>>> with
> > > >>>>>>
> > > >>>>>>> WYSIWYG editor for macro content and macro parameters.
> > > >>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>>> Cool :) We've been waiting for a long time about this
> > feature! See
> > > >>>>>>>>>>
> > > >>>>>>>>> below.
> > > >>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>>> The first step is to add a flag to allow user specify that a
> > > >>>>>>>>>>>
> > > >>>>>>>>>> content
> > > >>>>>>
> > > >>>>>>> or a parameter can be edited inline with the WYSIWYG editor.
> > > >>>>>>>>
> > > >>>>>>>>> The second step is to allow the CKEditor to detect where the
> > > >>>>>>>>>>>
> > > >>>>>>>>>> content
> > > >>>>>>
> > > >>>>>>> and/or parameters should be edited.
> > > >>>>>>>>
> > > >>>>>>>>> Let's take the exampe of a simple macro without any parameter,
> > > >>>>>>>>>>>
> > > >>>>>>>>>> which
> > > >>>>>>
> > > >>>>>>> currently produces this code:
> > > >>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>>>> <div class="box infomessage">
> > > >>>>>>>>>>>     <div class="title">
> > > >>>>>>>>>>>       <span class="icon info"></span>
> > > >>>>>>>>>>>       some title
> > > >>>>>>>>>>>     </div>
> > > >>>>>>>>>>>     Some content
> > > >>>>>>>>>>> </div>
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> We propose (me & Marius) to ask users to add a wrapper with a
> > > >>>>>>>>>>>
> > > >>>>>>>>>> specific class around the content to tell the editor it should
> > > >>>>>>>> only
> > > >>>>>>>>
> > > >>>>>>> allow
> > > >>>>>>
> > > >>>>>>> editing this content, e.g.:
> > > >>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>>>> <div class="box infomessage">
> > > >>>>>>>>>>>     <div class="title">
> > > >>>>>>>>>>>       <span class="icon info"></span>
> > > >>>>>>>>>>>       some title
> > > >>>>>>>>>>>     </div>
> > > >>>>>>>>>>>     <span class="editable-content">Some content</span>
> > > >>>>>>>>>>> </div>
> > > >>>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>> By “users”, I guess you mean macro developers?
> > > >>>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>> Here yes it's the macro developer. I'll try to be more
> > specific in
> > > >>>>>>>>> my
> > > >>>>>>>>> answers.
> > > >>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>>> So if I understand you well, you’re not planning to add a
> > > >>>>>>>>>>
> > > >>>>>>>>> getter/setters to the Macro descriptor, to tell that the macro
> > > >>>>>>>> content
> > > >>>>>>>> contains wiki markup and that it should be editable in the
> > WYSIWYG
> > > >>>>>>>>
> > > >>>>>>> editor?
> > > >>>>>>
> > > >>>>>>>
> > > >>>>>>>>> Actually we're planning to add the getter/setter **and** the
> > > >>>>>>>>> specific
> > > >>>>>>>>> markup for the editor. The getter/setter (which I called the
> > flag
> > > >>>>>>>>> above), is here to specify that the macro will contain inline
> > > >>>>>>>>>
> > > >>>>>>>> editable
> > > >>>>>>
> > > >>>>>>> content in WYSIWYG. The markup will specify *where* exactly is
> > this
> > > >>>>>>>>> content, and what shouldn't be changed.
> > > >>>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>> About that "flag", you seems to plan a boolean but I feel
> > something
> > > >>>>>>>> more generic that we want to introduce since a long time would
> > be
> > > >>>>>>>> better: make the content descriptor return a type like
> > parameters
> > > >>>>>>>> descriptors do. The kind of inline editing you have in mind
> > right
> > > >>>>>>>> now
> > > >>>>>>>> would then be associated to the type List<Block> for example (or
> > > >>>>>>>> CompositeBlock
> > > >>>>>>>>
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>> or some another type if we want to differentiate
> > > >>>>>>>> between wiki content modified by the macro and wiki content not
> > > >>>>>>>> modified by the macro
> > > >>>>>>>>
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>> We need this differentiation.
> > > >>>>>>>
> > > >>>>>>
> > > >>>>>> Sure but as I said you can differentiate using types too and we
> > need
> > > >>>>>> content types for other use cases so it's a good occasion. Also
> > when
> > > >>>>>> you use the type you can differentiate between wiki content and
> > HTML
> > > >>>>>> content and support inline editing of HTML macro in the same
> > system
> > > >>>>>> for example.
> > > >>>>>>
> > > >>>>>>
> > > >>>>> I'm not against your proposal. It's a bit more work though, to
> > define
> > > >>>>> the
> > > >>>>> types, but I suppose it's worth the effort.
> > > >>>>>
> > > >>>>
> > > >>> It's not much more work, just need to define one type for the current
> > > >>> use case ("final" wiki content). Other types can come later when
> > > >>> implementing support for them.
> > > >>>
> > > >>>
> > > >>>>>
> > > >>>>>
> > > >>>> So if I follow the idea would be to use this type defined for the
> > > >>>> content descriptor to specify the behaviour of the editor: e.g. if
> > the
> > > >>>> content descriptor is defined as an html content, then the html
> > editor
> > > >>>> would be used, if it's defined as an inline content, then it would
> > be an
> > > >>>> editor with limitation to clean html and line returns, etc.
> > > >>>>
> > > >>>> Still it does not change the need to specify which elements of the
> > > >>>> content are editable, right?
> > > >>>>
> > > >>>
> > > >>> Sure but that's the "second step". I only talked about replacing the
> > > >>> flag you defined as the first step by a more generic type :)
> > > >>>
> > > >>>
> > > >>>> Moreover I've the feeling that the parameters are already not
> > supporting
> > > >>>> the different types for edition (e.g. a boolean parameter only
> > shows a
> > > >>>> text input). So wouldn't it be a priority before putting a type on
> > the
> > > >>>> content descriptor itself?
> > > >>>>
> > > >>>
> > > >>> The WYSIWYG does miss a lot of displayers and we need work on that
> > for
> > > >>> sure but:
> > > >>> * you get a checkbox for boolean properties so the type is taken into
> > > >>> account
> > > >>> * having more specific displayers is not a requirement for working on
> > > >>> inline wiki editing
> > > >>>
> > > >>>
> > > >>>>
> > > >>>>>>
> > > >>>>>>>
> > > >>>>>>> ). The other types would be used in other use
> > > >>>>>>>> cases (syntax coloring for scripts, json editor, etc.). The
> > idea of
> > > >>>>>>>> using Java type is to be consistent with parameters and reuse
> > > >>>>>>>> existing
> > > >>>>>>>> the displayers in the macro modal window for example but it can
> > > >>>>>>>> cover
> > > >>>>>>>> this need too.
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>>> I guess that if the flag is set and the markup is not present,
> > then
> > > >>>>>>>>>
> > > >>>>>>>> the
> > > >>>>>>
> > > >>>>>>> entire content is considered as editable.
> > > >>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>>> Is that because you want to be finer-grained and have macro
> > > >>>>>>>>>> content
> > > >>>>>>>>>>
> > > >>>>>>>>> which can have parts editable with the WYSIWYG while having
> > other
> > > >>>>>>>>
> > > >>>>>>> parts of
> > > >>>>>>
> > > >>>>>>> the content not editable (for example)?
> > > >>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>> It's exactly why yes. On my example, the macro user won't be
> > able
> > > >>>>>>>>> to
> > > >>>>>>>>> change the content of the title.
> > > >>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>>> Technically Macros don’t generate HTML, only XDOM. So in
> > order to
> > > >>>>>>>>>>
> > > >>>>>>>>> make
> > > >>>>>>
> > > >>>>>>> it easier for java macro developers, I’d suggest to introduce
> > some
> > > >>>>>>>> new
> > > >>>>>>>> wrapping Block to indicate this information. We might need
> > something
> > > >>>>>>>> similar for wiki macros too, to make it more reusable and typed.
> > > >>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>> I'd need to look more on wrapping block but after a quick
> > overlook
> > > >>>>>>>>> it
> > > >>>>>>>>> seems to make sense indeed.
> > > >>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>>> About parameters, our idea was to define a new metadata
> > attribute
> > > >>>>>>>>>>>
> > > >>>>>>>>>> and
> > > >>>>>>
> > > >>>>>>> to ask users to use it for specifying the content is editable,
> > such
> > > >>>>>>>> as
> > > >>>>>>>>
> > > >>>>>>> for
> > > >>>>>>
> > > >>>>>>> a parameter named foo:
> > > >>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>>>> <span class="editable-content" data-parameter="foo">my foo
> > > >>>>>>>>>>>
> > > >>>>>>>>>> parameter
> > > >>>>>>
> > > >>>>>>> value</span>
> > > >>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>>> What’s your idea for editing parameters requiring WYSIWYG?
> > How do
> > > >>>>>>>>>>
> > > >>>>>>>>> you
> > > >>>>>>
> > > >>>>>>> present them in the UI? Do you have any mockup?
> > > >>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>> I don't have any mockup right now. FTM I see it like this:
> > > >>>>>>>>>     - when creating the macro, the current text input are
> > improved
> > > >>>>>>>>> with
> > > >>>>>>>>> the CKEditor for the editable content/parameters
> > > >>>>>>>>>     - when editing the macro, you stay in the main editor UI,
> > but
> > > >>>>>>>>> the
> > > >>>>>>>>> content is now editable instead of opening back the macro UI
> > > >>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>>> However I don't know right now how the editor would manage
> > cases
> > > >>>>>>>>>>>
> > > >>>>>>>>>> such
> > > >>>>>>
> > > >>>>>>> as:
> > > >>>>>>>>
> > > >>>>>>>>> <span class="editable-content">Some content with <span
> > > >>>>>>>>>>>
> > > >>>>>>>>>> class="editable-content" data-parameter="myparameter">a
> > > >>>>>>>> parameter</span></span>
> > > >>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>>>> So:
> > > >>>>>>>>>>>     1. Do you agree on the usage of a class named
> > > >>>>>>>>>>> "editable-content"
> > > >>>>>>>>>>>
> > > >>>>>>>>>> which would be used as a tag to allow inline edition?
> > > >>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>>> Small details, there’s already the “contenteditable” notion
> > that
> > > >>>>>>>>>>
> > > >>>>>>>>> exists (see https://developer.mozilla.org/
> > > >>>>>>>> fr/docs/Web/HTML/Attributs_
> > > >>>>>>>> universels/contenteditable) so “editable-content” is quite
> > close.
> > > >>>>>>>> Maybe
> > > >>>>>>>> we should have something more xwiki-specific? or more
> > > >>>>>>>> WYSIWYG-specific?
> > > >>>>>>>> Like “editable-wysiwyg” or “wysiwyg-editable”.
> > > >>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>> I'm open to suggestion on this one. "wysiwyg-editable" could be
> > > >>>>>>>>> nice.
> > > >>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>> My main comment is what I put above: how do we make it easy
> > for
> > > >>>>>>>>>>
> > > >>>>>>>>> macro
> > > >>>>>>
> > > >>>>>>> developers to specify this information.
> > > >>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>>>     2. WDYT about using a data-parameter and this class for
> > inline
> > > >>>>>>>>>>>
> > > >>>>>>>>>> editing of parameters?
> > > >>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>>> Before answering that part, I would need to understand what’s
> > the
> > > >>>>>>>>>>
> > > >>>>>>>>> proposal in term of UI.
> > > >>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>>> Note that the main use case is for content but it’s nice if
> > you
> > > >>>>>>>>>> can
> > > >>>>>>>>>>
> > > >>>>>>>>> also support parameters. Now, accepting markup in parameters
> > is not
> > > >>>>>>>>
> > > >>>>>>> really
> > > >>>>>>
> > > >>>>>>> a great use case IMO and is usually a design issue so I’m not
> > sure we
> > > >>>>>>>> should spend that much time in supporting that. WDYT?
> > > >>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>> We just discuss about macro parameters with Ludovic and
> > apparently
> > > >>>>>>>>>
> > > >>>>>>>> they
> > > >>>>>>
> > > >>>>>>> cannot support line returns, so we might have to use a custom
> > editor
> > > >>>>>>>>>
> > > >>>>>>>> for
> > > >>>>>>
> > > >>>>>>> those.
> > > >>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>>> The only macro parameter I know ATM that supports markup is
> > the
> > > >>>>>>>>>>
> > > >>>>>>>>> “title” param of the {{box}} macro and I think it’s badly
> > designed.
> > > >>>>>>>>
> > > >>>>>>> Note:
> > > >>>>>>
> > > >>>>>>> if you check the recent {{figure}} macro, I implemented this
> > need by
> > > >>>>>>>>
> > > >>>>>>> having
> > > >>>>>>
> > > >>>>>>> a {{figureCaption}} nested macro.
> > > >>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>>> BTW this raises a question, will you support WYSIWYG editing
> > of
> > > >>>>>>>>>>
> > > >>>>>>>>> nested
> > > >>>>>>
> > > >>>>>>> macros?
> > > >>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>> Not for the moment.
> > > >>>>>>>>>
> > > >>>>>>>>> Simon
> > > >>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>> Thanks
> > > >>>>>>>>>> -Vincent
> > > >>>>>>>>>>
> > > >>>>>>>>>> Thanks,
> > > >>>>>>>>>>> Simon
> > > >>>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>> [snip]
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>> --
> > > >>>>>>>>> Simon Urli
> > > >>>>>>>>> Software Engineer at XWiki SAS
> > > >>>>>>>>> [hidden email]
> > > >>>>>>>>> More about us at http://www.xwiki.com
> > > >>>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>> --
> > > >>>>>>>> Thomas Mortagne
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>>>> --
> > > >>>>>> Thomas Mortagne
> > > >>>>>>
> > > >>>>>>
> > > >>>> --
> > > >>>> Simon Urli
> > > >>>> Software Engineer at XWiki SAS
> > > >>>> [hidden email]
> > > >>>> More about us at http://www.xwiki.com
> > > >>>>
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >> --
> > > >> Simon Urli
> > > >> Software Engineer at XWiki SAS
> > > >> [hidden email]
> > > >> More about us at http://www.xwiki.com
> > > >>
> > > >
> > > >
> >
> >
> >
> > --
> > Thomas Mortagne
> >



--
Thomas Mortagne
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for Macro inline edition

Denis Gervalle-2
In reply to this post by Thomas Mortagne

--
Denis Gervalle
SOFTEC sa - CEO
On 12 Sep 2018, 17:20 +0200, Thomas Mortagne <[hidden email]>, wrote:

> On Wed, Sep 12, 2018 at 5:16 PM Marius Dumitru Florea
> <[hidden email]> wrote:
> >
> > On Wed, Sep 12, 2018 at 6:02 PM, Marius Dumitru Florea <
> > [hidden email]> wrote:
> >
> > > On Wed, Sep 12, 2018 at 5:18 PM, Simon Urli <[hidden email]> wrote:
> > >
> > > > Hello everyone,
> > > >
> > > > as a follow up of this proposal and the discussion we had, I just created
> > > > the following design proposal:
> > > >
> > > > https://design.xwiki.org/xwiki/bin/view/Main/MacroInlineEditingContent/
> > > >
> > > > Let me know what you think about it.
> > > >
> > >
> > > Regarding the Content Descriptor, which Syntax(es) will activate the
> > > inline editing of the macro content? I'm asking because the Syntax of the
> > > content is not the most important part. The most important part for the
> > > WYSIWYG editor is to know if the macro code outputs the macro content
> > > without transforming it. Without this it cannot enable inline editing. If
> > > the macro output is rendered without modifications then the WYSIWYG editor
> > > can enable inline editing but it needs to know in which Syntax to convert
> > > the HTML produced while editing inline. So to summarize:
> > >
> > > * First the WYSIWYG editor needs to know if the macro content is rendered
> > > without modifications
> > > * then the WYSIWYG editor needs to know the target Syntax to which to
> > > convert the HTML
> > >
> >
> > Let me try to make this even more clear. The WYSIWYG editor needs to take
> > the following decisions:
> >
> > [OPTIONAL] "Should I display the macro content (plain) text area on the
> > Macro Edit dialog?"
> >
> > If the macro content can be edited inline within the editing area then it
> > probably make sense to not display the text area on the Macro Edit dialog.
> > But for this we need some *static* information in the macro descriptor to
> > indicate that the macro content can be edited inline.
> >
> > [MANDATORY] "Should I enable inline editing for this macro?"
> >
> > The WYSIWYG editor can scan the macro output DOM (HTML) for some special
> > markers (attributes) to determine if the macro content can be edited inline
> >
>
>
> > [MANDATORY] "To which syntax do I need to convert the HTML from the macro
> > content?"
> >
> > When saving the page the editor needs to convert the macro content from
> > HTML to some syntax. The target syntax needs to be specified either in the
> > macro output DOM (HTML) using some attributes or in the macro descriptor.
>
> That's only if the syntax is different from the current syntax (which
> is not the case for most inline edited macros containing wiki
> content).

Well according to the idea that macro content, or even macro parameter could be used to render the content of the macro, this is even more complex since there could be for a single macro, multiple editable area, that could go either to a parameter or the content of the macro, and each of these areas could have a different syntax supported.

I would also add that it should also be useful to communicate to the editor the type of formatting allowed in these contents. Sometime, you wish only simple inline formatting like bold, italic… but you might also support block formatting like paragraph and list. So, the editable areas should be aware of this to properly update the editor tool bar and prevent unsupported html to have to be converted. If you take a simple titled box macro, you have a title that goes to a parameter, could be plain text or better xwiki syntax, but only allow inline formatting like bold/italic/superscripts… since it is rendered in a h tag, and a macro content in full wiki syntax that could hold paragraphs, list and everything.

>
> >
> > Hope this helps,
> > Marius
> >
> >
> > >
> > >
> > > >
> > > > Thanks,
> > > > Simon
> > > >
> > > >
> > > > On 9/10/18 6:46 PM, Thomas Mortagne wrote:
> > > >
> > > > > On Mon, Sep 10, 2018 at 3:47 PM Simon Urli <[hidden email]> wrote:
> > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On 9/10/18 3:24 PM, Marius Dumitru Florea wrote:
> > > > > >
> > > > > > > On Mon, Sep 10, 2018 at 4:07 PM, Thomas Mortagne <
> > > > > > > [hidden email]>
> > > > > > > wrote:
> > > > > > >
> > > > > > > On Mon, Sep 10, 2018 at 2:56 PM Marius Dumitru Florea
> > > > > > > > <[hidden email]> wrote:
> > > > > > > >
> > > > > > > > >
> > > > > > > > > On Mon, Sep 10, 2018 at 3:42 PM, Thomas Mortagne <
> > > > > > > > >
> > > > > > > > [hidden email]>
> > > > > > > >
> > > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > On Mon, Sep 10, 2018 at 2:13 PM Simon Urli <[hidden email]>
> > > > > > > > > >
> > > > > > > > > wrote:
> > > > > > > >
> > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > On 9/10/18 1:35 PM, Vincent Massol wrote:
> > > > > > > > > > >
> > > > > > > > > > > > Hi Simon,
> > > > > > > > > > > >
> > > > > > > > > > > > On 10 Sep 2018, at 13:05, Simon Urli <[hidden email]>
> > > > > > > > > > > > >
> > > > > > > > > > > > wrote:
> > > > > > > >
> > > > > > > > >
> > > > > > > > > > > > > Hi everyone,
> > > > > > > > > > > > >
> > > > > > > > > > > > > I'm working on the roadmap issues related to the inline edition
> > > > > > > > > > > > >
> > > > > > > > > > > > with
> > > > > > > >
> > > > > > > > > WYSIWYG editor for macro content and macro parameters.
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > > Cool :) We've been waiting for a long time about this feature! See
> > > > > > > > > > > >
> > > > > > > > > > > below.
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > > The first step is to add a flag to allow user specify that a
> > > > > > > > > > > > >
> > > > > > > > > > > > content
> > > > > > > >
> > > > > > > > > or a parameter can be edited inline with the WYSIWYG editor.
> > > > > > > > > >
> > > > > > > > > > > The second step is to allow the CKEditor to detect where the
> > > > > > > > > > > > >
> > > > > > > > > > > > content
> > > > > > > >
> > > > > > > > > and/or parameters should be edited.
> > > > > > > > > >
> > > > > > > > > > > Let's take the exampe of a simple macro without any parameter,
> > > > > > > > > > > > >
> > > > > > > > > > > > which
> > > > > > > >
> > > > > > > > > currently produces this code:
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > > > <div class="box infomessage">
> > > > > > > > > > > > > <div class="title">
> > > > > > > > > > > > > <span class="icon info"></span>
> > > > > > > > > > > > > some title
> > > > > > > > > > > > > </div>
> > > > > > > > > > > > > Some content
> > > > > > > > > > > > > </div>
> > > > > > > > > > > > >
> > > > > > > > > > > > > We propose (me & Marius) to ask users to add a wrapper with a
> > > > > > > > > > > > >
> > > > > > > > > > > > specific class around the content to tell the editor it should
> > > > > > > > > > only
> > > > > > > > > >
> > > > > > > > > allow
> > > > > > > >
> > > > > > > > > editing this content, e.g.:
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > > > <div class="box infomessage">
> > > > > > > > > > > > > <div class="title">
> > > > > > > > > > > > > <span class="icon info"></span>
> > > > > > > > > > > > > some title
> > > > > > > > > > > > > </div>
> > > > > > > > > > > > > <span class="editable-content">Some content</span>
> > > > > > > > > > > > > </div>
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > By “users”, I guess you mean macro developers?
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > Here yes it's the macro developer. I'll try to be more specific in
> > > > > > > > > > > my
> > > > > > > > > > > answers.
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > > So if I understand you well, you’re not planning to add a
> > > > > > > > > > > >
> > > > > > > > > > > getter/setters to the Macro descriptor, to tell that the macro
> > > > > > > > > > content
> > > > > > > > > > contains wiki markup and that it should be editable in the WYSIWYG
> > > > > > > > > >
> > > > > > > > > editor?
> > > > > > > >
> > > > > > > > >
> > > > > > > > > > > Actually we're planning to add the getter/setter **and** the
> > > > > > > > > > > specific
> > > > > > > > > > > markup for the editor. The getter/setter (which I called the flag
> > > > > > > > > > > above), is here to specify that the macro will contain inline
> > > > > > > > > > >
> > > > > > > > > > editable
> > > > > > > >
> > > > > > > > > content in WYSIWYG. The markup will specify *where* exactly is this
> > > > > > > > > > > content, and what shouldn't be changed.
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > About that "flag", you seems to plan a boolean but I feel something
> > > > > > > > > > more generic that we want to introduce since a long time would be
> > > > > > > > > > better: make the content descriptor return a type like parameters
> > > > > > > > > > descriptors do. The kind of inline editing you have in mind right
> > > > > > > > > > now
> > > > > > > > > > would then be associated to the type List<Block> for example (or
> > > > > > > > > > CompositeBlock
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > or some another type if we want to differentiate
> > > > > > > > > > between wiki content modified by the macro and wiki content not
> > > > > > > > > > modified by the macro
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > We need this differentiation.
> > > > > > > > >
> > > > > > > >
> > > > > > > > Sure but as I said you can differentiate using types too and we need
> > > > > > > > content types for other use cases so it's a good occasion. Also when
> > > > > > > > you use the type you can differentiate between wiki content and HTML
> > > > > > > > content and support inline editing of HTML macro in the same system
> > > > > > > > for example.
> > > > > > > >
> > > > > > > >
> > > > > > > I'm not against your proposal. It's a bit more work though, to define
> > > > > > > the
> > > > > > > types, but I suppose it's worth the effort.
> > > > > > >
> > > > > >
> > > > > It's not much more work, just need to define one type for the current
> > > > > use case ("final" wiki content). Other types can come later when
> > > > > implementing support for them.
> > > > >
> > > > >
> > > > > > >
> > > > > > >
> > > > > > So if I follow the idea would be to use this type defined for the
> > > > > > content descriptor to specify the behaviour of the editor: e.g. if the
> > > > > > content descriptor is defined as an html content, then the html editor
> > > > > > would be used, if it's defined as an inline content, then it would be an
> > > > > > editor with limitation to clean html and line returns, etc.
> > > > > >
> > > > > > Still it does not change the need to specify which elements of the
> > > > > > content are editable, right?
> > > > > >
> > > > >
> > > > > Sure but that's the "second step". I only talked about replacing the
> > > > > flag you defined as the first step by a more generic type :)
> > > > >
> > > > >
> > > > > > Moreover I've the feeling that the parameters are already not supporting
> > > > > > the different types for edition (e.g. a boolean parameter only shows a
> > > > > > text input). So wouldn't it be a priority before putting a type on the
> > > > > > content descriptor itself?
> > > > > >
> > > > >
> > > > > The WYSIWYG does miss a lot of displayers and we need work on that for
> > > > > sure but:
> > > > > * you get a checkbox for boolean properties so the type is taken into
> > > > > account
> > > > > * having more specific displayers is not a requirement for working on
> > > > > inline wiki editing
> > > > >
> > > > >
> > > > > >
> > > > > > > >
> > > > > > > > >
> > > > > > > > > ). The other types would be used in other use
> > > > > > > > > > cases (syntax coloring for scripts, json editor, etc.). The idea of
> > > > > > > > > > using Java type is to be consistent with parameters and reuse
> > > > > > > > > > existing
> > > > > > > > > > the displayers in the macro modal window for example but it can
> > > > > > > > > > cover
> > > > > > > > > > this need too.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > > I guess that if the flag is set and the markup is not present, then
> > > > > > > > > > >
> > > > > > > > > > the
> > > > > > > >
> > > > > > > > > entire content is considered as editable.
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > > Is that because you want to be finer-grained and have macro
> > > > > > > > > > > > content
> > > > > > > > > > > >
> > > > > > > > > > > which can have parts editable with the WYSIWYG while having other
> > > > > > > > > >
> > > > > > > > > parts of
> > > > > > > >
> > > > > > > > > the content not editable (for example)?
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > It's exactly why yes. On my example, the macro user won't be able
> > > > > > > > > > > to
> > > > > > > > > > > change the content of the title.
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > > Technically Macros don’t generate HTML, only XDOM. So in order to
> > > > > > > > > > > >
> > > > > > > > > > > make
> > > > > > > >
> > > > > > > > > it easier for java macro developers, I’d suggest to introduce some
> > > > > > > > > > new
> > > > > > > > > > wrapping Block to indicate this information. We might need something
> > > > > > > > > > similar for wiki macros too, to make it more reusable and typed.
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > I'd need to look more on wrapping block but after a quick overlook
> > > > > > > > > > > it
> > > > > > > > > > > seems to make sense indeed.
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > > About parameters, our idea was to define a new metadata attribute
> > > > > > > > > > > > >
> > > > > > > > > > > > and
> > > > > > > >
> > > > > > > > > to ask users to use it for specifying the content is editable, such
> > > > > > > > > > as
> > > > > > > > > >
> > > > > > > > > for
> > > > > > > >
> > > > > > > > > a parameter named foo:
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > > > <span class="editable-content" data-parameter="foo">my foo
> > > > > > > > > > > > >
> > > > > > > > > > > > parameter
> > > > > > > >
> > > > > > > > > value</span>
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > > What’s your idea for editing parameters requiring WYSIWYG? How do
> > > > > > > > > > > >
> > > > > > > > > > > you
> > > > > > > >
> > > > > > > > > present them in the UI? Do you have any mockup?
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > I don't have any mockup right now. FTM I see it like this:
> > > > > > > > > > > - when creating the macro, the current text input are improved
> > > > > > > > > > > with
> > > > > > > > > > > the CKEditor for the editable content/parameters
> > > > > > > > > > > - when editing the macro, you stay in the main editor UI, but
> > > > > > > > > > > the
> > > > > > > > > > > content is now editable instead of opening back the macro UI
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > > However I don't know right now how the editor would manage cases
> > > > > > > > > > > > >
> > > > > > > > > > > > such
> > > > > > > >
> > > > > > > > > as:
> > > > > > > > > >
> > > > > > > > > > > <span class="editable-content">Some content with <span
> > > > > > > > > > > > >
> > > > > > > > > > > > class="editable-content" data-parameter="myparameter">a
> > > > > > > > > > parameter</span></span>
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > > > So:
> > > > > > > > > > > > > 1. Do you agree on the usage of a class named
> > > > > > > > > > > > > "editable-content"
> > > > > > > > > > > > >
> > > > > > > > > > > > which would be used as a tag to allow inline edition?
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > > Small details, there’s already the “contenteditable” notion that
> > > > > > > > > > > >
> > > > > > > > > > > exists (see https://developer.mozilla.org/
> > > > > > > > > > fr/docs/Web/HTML/Attributs_
> > > > > > > > > > universels/contenteditable) so “editable-content” is quite close.
> > > > > > > > > > Maybe
> > > > > > > > > > we should have something more xwiki-specific? or more
> > > > > > > > > > WYSIWYG-specific?
> > > > > > > > > > Like “editable-wysiwyg” or “wysiwyg-editable”.
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > I'm open to suggestion on this one. "wysiwyg-editable" could be
> > > > > > > > > > > nice.
> > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > My main comment is what I put above: how do we make it easy for
> > > > > > > > > > > >
> > > > > > > > > > > macro
> > > > > > > >
> > > > > > > > > developers to specify this information.
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > > 2. WDYT about using a data-parameter and this class for inline
> > > > > > > > > > > > >
> > > > > > > > > > > > editing of parameters?
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > > Before answering that part, I would need to understand what’s the
> > > > > > > > > > > >
> > > > > > > > > > > proposal in term of UI.
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > > Note that the main use case is for content but it’s nice if you
> > > > > > > > > > > > can
> > > > > > > > > > > >
> > > > > > > > > > > also support parameters. Now, accepting markup in parameters is not
> > > > > > > > > >
> > > > > > > > > really
> > > > > > > >
> > > > > > > > > a great use case IMO and is usually a design issue so I’m not sure we
> > > > > > > > > > should spend that much time in supporting that. WDYT?
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > We just discuss about macro parameters with Ludovic and apparently
> > > > > > > > > > >
> > > > > > > > > > they
> > > > > > > >
> > > > > > > > > cannot support line returns, so we might have to use a custom editor
> > > > > > > > > > >
> > > > > > > > > > for
> > > > > > > >
> > > > > > > > > those.
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > > The only macro parameter I know ATM that supports markup is the
> > > > > > > > > > > >
> > > > > > > > > > > “title” param of the {{box}} macro and I think it’s badly designed.
> > > > > > > > > >
> > > > > > > > > Note:
> > > > > > > >
> > > > > > > > > if you check the recent {{figure}} macro, I implemented this need by
> > > > > > > > > >
> > > > > > > > > having
> > > > > > > >
> > > > > > > > > a {{figureCaption}} nested macro.
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > > BTW this raises a question, will you support WYSIWYG editing of
> > > > > > > > > > > >
> > > > > > > > > > > nested
> > > > > > > >
> > > > > > > > > macros?
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > Not for the moment.
> > > > > > > > > > >
> > > > > > > > > > > Simon
> > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > Thanks
> > > > > > > > > > > > -Vincent
> > > > > > > > > > > >
> > > > > > > > > > > > Thanks,
> > > > > > > > > > > > > Simon
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > [snip]
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > --
> > > > > > > > > > > Simon Urli
> > > > > > > > > > > Software Engineer at XWiki SAS
> > > > > > > > > > > [hidden email]
> > > > > > > > > > > More about us at http://www.xwiki.com
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > --
> > > > > > > > > > Thomas Mortagne
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Thomas Mortagne
> > > > > > > >
> > > > > > > >
> > > > > > --
> > > > > > Simon Urli
> > > > > > Software Engineer at XWiki SAS
> > > > > > [hidden email]
> > > > > > More about us at http://www.xwiki.com
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > --
> > > > Simon Urli
> > > > Software Engineer at XWiki SAS
> > > > [hidden email]
> > > > More about us at http://www.xwiki.com
> > > >
> > >
> > >
>
>
>
> --
> Thomas Mortagne
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for Macro inline edition

Marius Dumitru Florea
In reply to this post by Thomas Mortagne
On Wed, Sep 12, 2018 at 6:30 PM, Thomas Mortagne <[hidden email]>
wrote:

> On Wed, Sep 12, 2018 at 5:27 PM Marius Dumitru Florea
> <[hidden email]> wrote:
> >
> > On Wed, Sep 12, 2018 at 6:20 PM, Thomas Mortagne <
> [hidden email]>
> > wrote:
> >
> > > On Wed, Sep 12, 2018 at 5:16 PM Marius Dumitru Florea
> > > <[hidden email]> wrote:
> > > >
> > > > On Wed, Sep 12, 2018 at 6:02 PM, Marius Dumitru Florea <
> > > > [hidden email]> wrote:
> > > >
> > > > > On Wed, Sep 12, 2018 at 5:18 PM, Simon Urli <[hidden email]>
> > > wrote:
> > > > >
> > > > >> Hello everyone,
> > > > >>
> > > > >> as a follow up of this proposal and the discussion we had, I just
> > > created
> > > > >> the following design proposal:
> > > > >>
> > > > >> https://design.xwiki.org/xwiki/bin/view/Main/
> > > MacroInlineEditingContent/
> > > > >>
> > > > >> Let me know what you think about it.
> > > > >>
> > > > >
> > > > > Regarding the Content Descriptor, which Syntax(es) will activate
> the
> > > > > inline editing of the macro content? I'm asking because the Syntax
> of
> > > the
> > > > > content is not the most important part. The most important part
> for the
> > > > > WYSIWYG editor is to know if the macro code outputs the macro
> content
> > > > > without transforming it. Without this it cannot enable inline
> editing.
> > > If
> > > > > the macro output is rendered without modifications then the WYSIWYG
> > > editor
> > > > > can enable inline editing but it needs to know in which Syntax to
> > > convert
> > > > > the HTML produced while editing inline. So to summarize:
> > > > >
> > > > > * First the WYSIWYG editor needs to know if the macro content is
> > > rendered
> > > > > without modifications
> > > > > * then the WYSIWYG editor needs to know the target Syntax to which
> to
> > > > > convert the HTML
> > > > >
> > > >
> > > > Let me try to make this even more clear.  The WYSIWYG editor needs to
> > > take
> > > > the following decisions:
> > > >
> > > > [OPTIONAL] "Should I display the macro content (plain) text area on
> the
> > > > Macro Edit dialog?"
> > > >
> > > > If the macro content can be edited inline within the editing area
> then it
> > > > probably make sense to not display the text area on the Macro Edit
> > > dialog.
> > > > But for this we need some *static* information in the macro
> descriptor to
> > > > indicate that the macro content can be edited inline.
> > > >
> > > > [MANDATORY] "Should I enable inline editing for this macro?"
> > > >
> > > > The WYSIWYG editor can scan the macro output DOM (HTML) for some
> special
> > > > markers (attributes) to determine if the macro content can be edited
> > > inline
> > > >
> > >
> > >
> > > > [MANDATORY] "To which syntax do I need to convert the HTML from the
> macro
> > > > content?"
> > > >
> > > > When saving the page the editor needs to convert the macro content
> from
> > > > HTML to some syntax. The target syntax needs to be specified either
> in
> > > the
> > > > macro output DOM (HTML) using some attributes or in the macro
> descriptor.
> > >
> > >
> >
> > > That's only if the syntax is different from the current syntax (which
> > > is not the case for most inline edited macros containing wiki
> > > content).
> > >
> >
> > Exactly! The macros we target with this feature use the current syntax
> (of
> > the page where the macro is called) for their content.
>
>

> My point is that the WYSIWYG know the syntax already you don't need
> each macro to provide it as metadata.
>

I fully agree with you.


>
> >
> >
> > >
> > > >
> > > > Hope this helps,
> > > > Marius
> > > >
> > > >
> > > > >
> > > > >
> > > > >>
> > > > >> Thanks,
> > > > >> Simon
> > > > >>
> > > > >>
> > > > >> On 9/10/18 6:46 PM, Thomas Mortagne wrote:
> > > > >>
> > > > >>> On Mon, Sep 10, 2018 at 3:47 PM Simon Urli <[hidden email]
> >
> > > wrote:
> > > > >>>
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >>>> On 9/10/18 3:24 PM, Marius Dumitru Florea wrote:
> > > > >>>>
> > > > >>>>> On Mon, Sep 10, 2018 at 4:07 PM, Thomas Mortagne <
> > > > >>>>> [hidden email]>
> > > > >>>>> wrote:
> > > > >>>>>
> > > > >>>>> On Mon, Sep 10, 2018 at 2:56 PM Marius Dumitru Florea
> > > > >>>>>> <[hidden email]> wrote:
> > > > >>>>>>
> > > > >>>>>>>
> > > > >>>>>>> On Mon, Sep 10, 2018 at 3:42 PM, Thomas Mortagne <
> > > > >>>>>>>
> > > > >>>>>> [hidden email]>
> > > > >>>>>>
> > > > >>>>>>> wrote:
> > > > >>>>>>>
> > > > >>>>>>> On Mon, Sep 10, 2018 at 2:13 PM Simon Urli <
> [hidden email]
> > > >
> > > > >>>>>>>>
> > > > >>>>>>> wrote:
> > > > >>>>>>
> > > > >>>>>>>
> > > > >>>>>>>>>
> > > > >>>>>>>>>
> > > > >>>>>>>>> On 9/10/18 1:35 PM, Vincent Massol wrote:
> > > > >>>>>>>>>
> > > > >>>>>>>>>> Hi Simon,
> > > > >>>>>>>>>>
> > > > >>>>>>>>>> On 10 Sep 2018, at 13:05, Simon Urli <
> [hidden email]>
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>> wrote:
> > > > >>>>>>
> > > > >>>>>>>
> > > > >>>>>>>>>>> Hi everyone,
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>> I'm working on the roadmap issues related to the inline
> > > edition
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>> with
> > > > >>>>>>
> > > > >>>>>>> WYSIWYG editor for macro content and macro parameters.
> > > > >>>>>>>>
> > > > >>>>>>>>>
> > > > >>>>>>>>>> Cool :) We've been waiting for a long time about this
> > > feature! See
> > > > >>>>>>>>>>
> > > > >>>>>>>>> below.
> > > > >>>>>>>>
> > > > >>>>>>>>>
> > > > >>>>>>>>>> The first step is to add a flag to allow user specify
> that a
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>> content
> > > > >>>>>>
> > > > >>>>>>> or a parameter can be edited inline with the WYSIWYG editor.
> > > > >>>>>>>>
> > > > >>>>>>>>> The second step is to allow the CKEditor to detect where
> the
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>> content
> > > > >>>>>>
> > > > >>>>>>> and/or parameters should be edited.
> > > > >>>>>>>>
> > > > >>>>>>>>> Let's take the exampe of a simple macro without any
> parameter,
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>> which
> > > > >>>>>>
> > > > >>>>>>> currently produces this code:
> > > > >>>>>>>>
> > > > >>>>>>>>>
> > > > >>>>>>>>>>> <div class="box infomessage">
> > > > >>>>>>>>>>>     <div class="title">
> > > > >>>>>>>>>>>       <span class="icon info"></span>
> > > > >>>>>>>>>>>       some title
> > > > >>>>>>>>>>>     </div>
> > > > >>>>>>>>>>>     Some content
> > > > >>>>>>>>>>> </div>
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>> We propose (me & Marius) to ask users to add a wrapper
> with a
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>> specific class around the content to tell the editor it
> should
> > > > >>>>>>>> only
> > > > >>>>>>>>
> > > > >>>>>>> allow
> > > > >>>>>>
> > > > >>>>>>> editing this content, e.g.:
> > > > >>>>>>>>
> > > > >>>>>>>>>
> > > > >>>>>>>>>>> <div class="box infomessage">
> > > > >>>>>>>>>>>     <div class="title">
> > > > >>>>>>>>>>>       <span class="icon info"></span>
> > > > >>>>>>>>>>>       some title
> > > > >>>>>>>>>>>     </div>
> > > > >>>>>>>>>>>     <span class="editable-content">Some content</span>
> > > > >>>>>>>>>>> </div>
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>
> > > > >>>>>>>>>> By “users”, I guess you mean macro developers?
> > > > >>>>>>>>>>
> > > > >>>>>>>>>
> > > > >>>>>>>>> Here yes it's the macro developer. I'll try to be more
> > > specific in
> > > > >>>>>>>>> my
> > > > >>>>>>>>> answers.
> > > > >>>>>>>>>
> > > > >>>>>>>>>
> > > > >>>>>>>>>> So if I understand you well, you’re not planning to add a
> > > > >>>>>>>>>>
> > > > >>>>>>>>> getter/setters to the Macro descriptor, to tell that the
> macro
> > > > >>>>>>>> content
> > > > >>>>>>>> contains wiki markup and that it should be editable in the
> > > WYSIWYG
> > > > >>>>>>>>
> > > > >>>>>>> editor?
> > > > >>>>>>
> > > > >>>>>>>
> > > > >>>>>>>>> Actually we're planning to add the getter/setter **and**
> the
> > > > >>>>>>>>> specific
> > > > >>>>>>>>> markup for the editor. The getter/setter (which I called
> the
> > > flag
> > > > >>>>>>>>> above), is here to specify that the macro will contain
> inline
> > > > >>>>>>>>>
> > > > >>>>>>>> editable
> > > > >>>>>>
> > > > >>>>>>> content in WYSIWYG. The markup will specify *where* exactly
> is
> > > this
> > > > >>>>>>>>> content, and what shouldn't be changed.
> > > > >>>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>>> About that "flag", you seems to plan a boolean but I feel
> > > something
> > > > >>>>>>>> more generic that we want to introduce since a long time
> would
> > > be
> > > > >>>>>>>> better: make the content descriptor return a type like
> > > parameters
> > > > >>>>>>>> descriptors do. The kind of inline editing you have in mind
> > > right
> > > > >>>>>>>> now
> > > > >>>>>>>> would then be associated to the type List<Block> for
> example (or
> > > > >>>>>>>> CompositeBlock
> > > > >>>>>>>>
> > > > >>>>>>>
> > > > >>>>>>>
> > > > >>>>>>>
> > > > >>>>>>> or some another type if we want to differentiate
> > > > >>>>>>>> between wiki content modified by the macro and wiki content
> not
> > > > >>>>>>>> modified by the macro
> > > > >>>>>>>>
> > > > >>>>>>>
> > > > >>>>>>>
> > > > >>>>>>> We need this differentiation.
> > > > >>>>>>>
> > > > >>>>>>
> > > > >>>>>> Sure but as I said you can differentiate using types too and
> we
> > > need
> > > > >>>>>> content types for other use cases so it's a good occasion.
> Also
> > > when
> > > > >>>>>> you use the type you can differentiate between wiki content
> and
> > > HTML
> > > > >>>>>> content and support inline editing of HTML macro in the same
> > > system
> > > > >>>>>> for example.
> > > > >>>>>>
> > > > >>>>>>
> > > > >>>>> I'm not against your proposal. It's a bit more work though, to
> > > define
> > > > >>>>> the
> > > > >>>>> types, but I suppose it's worth the effort.
> > > > >>>>>
> > > > >>>>
> > > > >>> It's not much more work, just need to define one type for the
> current
> > > > >>> use case ("final" wiki content). Other types can come later when
> > > > >>> implementing support for them.
> > > > >>>
> > > > >>>
> > > > >>>>>
> > > > >>>>>
> > > > >>>> So if I follow the idea would be to use this type defined for
> the
> > > > >>>> content descriptor to specify the behaviour of the editor: e.g.
> if
> > > the
> > > > >>>> content descriptor is defined as an html content, then the html
> > > editor
> > > > >>>> would be used, if it's defined as an inline content, then it
> would
> > > be an
> > > > >>>> editor with limitation to clean html and line returns, etc.
> > > > >>>>
> > > > >>>> Still it does not change the need to specify which elements of
> the
> > > > >>>> content are editable, right?
> > > > >>>>
> > > > >>>
> > > > >>> Sure but that's the "second step". I only talked about replacing
> the
> > > > >>> flag you defined as the first step by a more generic type :)
> > > > >>>
> > > > >>>
> > > > >>>> Moreover I've the feeling that the parameters are already not
> > > supporting
> > > > >>>> the different types for edition (e.g. a boolean parameter only
> > > shows a
> > > > >>>> text input). So wouldn't it be a priority before putting a type
> on
> > > the
> > > > >>>> content descriptor itself?
> > > > >>>>
> > > > >>>
> > > > >>> The WYSIWYG does miss a lot of displayers and we need work on
> that
> > > for
> > > > >>> sure but:
> > > > >>> * you get a checkbox for boolean properties so the type is taken
> into
> > > > >>> account
> > > > >>> * having more specific displayers is not a requirement for
> working on
> > > > >>> inline wiki editing
> > > > >>>
> > > > >>>
> > > > >>>>
> > > > >>>>>>
> > > > >>>>>>>
> > > > >>>>>>> ). The other types would be used in other use
> > > > >>>>>>>> cases (syntax coloring for scripts, json editor, etc.). The
> > > idea of
> > > > >>>>>>>> using Java type is to be consistent with parameters and
> reuse
> > > > >>>>>>>> existing
> > > > >>>>>>>> the displayers in the macro modal window for example but it
> can
> > > > >>>>>>>> cover
> > > > >>>>>>>> this need too.
> > > > >>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>>>> I guess that if the flag is set and the markup is not
> present,
> > > then
> > > > >>>>>>>>>
> > > > >>>>>>>> the
> > > > >>>>>>
> > > > >>>>>>> entire content is considered as editable.
> > > > >>>>>>>>>
> > > > >>>>>>>>>
> > > > >>>>>>>>>> Is that because you want to be finer-grained and have
> macro
> > > > >>>>>>>>>> content
> > > > >>>>>>>>>>
> > > > >>>>>>>>> which can have parts editable with the WYSIWYG while having
> > > other
> > > > >>>>>>>>
> > > > >>>>>>> parts of
> > > > >>>>>>
> > > > >>>>>>> the content not editable (for example)?
> > > > >>>>>>>>
> > > > >>>>>>>>>
> > > > >>>>>>>>> It's exactly why yes. On my example, the macro user won't
> be
> > > able
> > > > >>>>>>>>> to
> > > > >>>>>>>>> change the content of the title.
> > > > >>>>>>>>>
> > > > >>>>>>>>>
> > > > >>>>>>>>>> Technically Macros don’t generate HTML, only XDOM. So in
> > > order to
> > > > >>>>>>>>>>
> > > > >>>>>>>>> make
> > > > >>>>>>
> > > > >>>>>>> it easier for java macro developers, I’d suggest to introduce
> > > some
> > > > >>>>>>>> new
> > > > >>>>>>>> wrapping Block to indicate this information. We might need
> > > something
> > > > >>>>>>>> similar for wiki macros too, to make it more reusable and
> typed.
> > > > >>>>>>>>
> > > > >>>>>>>>>
> > > > >>>>>>>>> I'd need to look more on wrapping block but after a quick
> > > overlook
> > > > >>>>>>>>> it
> > > > >>>>>>>>> seems to make sense indeed.
> > > > >>>>>>>>>
> > > > >>>>>>>>>
> > > > >>>>>>>>>> About parameters, our idea was to define a new metadata
> > > attribute
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>> and
> > > > >>>>>>
> > > > >>>>>>> to ask users to use it for specifying the content is
> editable,
> > > such
> > > > >>>>>>>> as
> > > > >>>>>>>>
> > > > >>>>>>> for
> > > > >>>>>>
> > > > >>>>>>> a parameter named foo:
> > > > >>>>>>>>
> > > > >>>>>>>>>
> > > > >>>>>>>>>>> <span class="editable-content" data-parameter="foo">my
> foo
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>> parameter
> > > > >>>>>>
> > > > >>>>>>> value</span>
> > > > >>>>>>>>
> > > > >>>>>>>>>
> > > > >>>>>>>>>> What’s your idea for editing parameters requiring WYSIWYG?
> > > How do
> > > > >>>>>>>>>>
> > > > >>>>>>>>> you
> > > > >>>>>>
> > > > >>>>>>> present them in the UI? Do you have any mockup?
> > > > >>>>>>>>
> > > > >>>>>>>>>
> > > > >>>>>>>>> I don't have any mockup right now. FTM I see it like this:
> > > > >>>>>>>>>     - when creating the macro, the current text input are
> > > improved
> > > > >>>>>>>>> with
> > > > >>>>>>>>> the CKEditor for the editable content/parameters
> > > > >>>>>>>>>     - when editing the macro, you stay in the main editor
> UI,
> > > but
> > > > >>>>>>>>> the
> > > > >>>>>>>>> content is now editable instead of opening back the macro
> UI
> > > > >>>>>>>>>
> > > > >>>>>>>>>
> > > > >>>>>>>>>> However I don't know right now how the editor would manage
> > > cases
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>> such
> > > > >>>>>>
> > > > >>>>>>> as:
> > > > >>>>>>>>
> > > > >>>>>>>>> <span class="editable-content">Some content with <span
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>> class="editable-content" data-parameter="myparameter">a
> > > > >>>>>>>> parameter</span></span>
> > > > >>>>>>>>
> > > > >>>>>>>>>
> > > > >>>>>>>>>>> So:
> > > > >>>>>>>>>>>     1. Do you agree on the usage of a class named
> > > > >>>>>>>>>>> "editable-content"
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>> which would be used as a tag to allow inline edition?
> > > > >>>>>>>>
> > > > >>>>>>>>>
> > > > >>>>>>>>>> Small details, there’s already the “contenteditable”
> notion
> > > that
> > > > >>>>>>>>>>
> > > > >>>>>>>>> exists (see https://developer.mozilla.org/
> > > > >>>>>>>> fr/docs/Web/HTML/Attributs_
> > > > >>>>>>>> universels/contenteditable) so “editable-content” is quite
> > > close.
> > > > >>>>>>>> Maybe
> > > > >>>>>>>> we should have something more xwiki-specific? or more
> > > > >>>>>>>> WYSIWYG-specific?
> > > > >>>>>>>> Like “editable-wysiwyg” or “wysiwyg-editable”.
> > > > >>>>>>>>
> > > > >>>>>>>>>
> > > > >>>>>>>>> I'm open to suggestion on this one. "wysiwyg-editable"
> could be
> > > > >>>>>>>>> nice.
> > > > >>>>>>>>>
> > > > >>>>>>>>>>
> > > > >>>>>>>>>> My main comment is what I put above: how do we make it
> easy
> > > for
> > > > >>>>>>>>>>
> > > > >>>>>>>>> macro
> > > > >>>>>>
> > > > >>>>>>> developers to specify this information.
> > > > >>>>>>>>
> > > > >>>>>>>>>
> > > > >>>>>>>>>>     2. WDYT about using a data-parameter and this class
> for
> > > inline
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>> editing of parameters?
> > > > >>>>>>>>
> > > > >>>>>>>>>
> > > > >>>>>>>>>> Before answering that part, I would need to understand
> what’s
> > > the
> > > > >>>>>>>>>>
> > > > >>>>>>>>> proposal in term of UI.
> > > > >>>>>>>>
> > > > >>>>>>>>>
> > > > >>>>>>>>>> Note that the main use case is for content but it’s nice
> if
> > > you
> > > > >>>>>>>>>> can
> > > > >>>>>>>>>>
> > > > >>>>>>>>> also support parameters. Now, accepting markup in
> parameters
> > > is not
> > > > >>>>>>>>
> > > > >>>>>>> really
> > > > >>>>>>
> > > > >>>>>>> a great use case IMO and is usually a design issue so I’m not
> > > sure we
> > > > >>>>>>>> should spend that much time in supporting that. WDYT?
> > > > >>>>>>>>
> > > > >>>>>>>>>
> > > > >>>>>>>>> We just discuss about macro parameters with Ludovic and
> > > apparently
> > > > >>>>>>>>>
> > > > >>>>>>>> they
> > > > >>>>>>
> > > > >>>>>>> cannot support line returns, so we might have to use a custom
> > > editor
> > > > >>>>>>>>>
> > > > >>>>>>>> for
> > > > >>>>>>
> > > > >>>>>>> those.
> > > > >>>>>>>>>
> > > > >>>>>>>>>
> > > > >>>>>>>>>> The only macro parameter I know ATM that supports markup
> is
> > > the
> > > > >>>>>>>>>>
> > > > >>>>>>>>> “title” param of the {{box}} macro and I think it’s badly
> > > designed.
> > > > >>>>>>>>
> > > > >>>>>>> Note:
> > > > >>>>>>
> > > > >>>>>>> if you check the recent {{figure}} macro, I implemented this
> > > need by
> > > > >>>>>>>>
> > > > >>>>>>> having
> > > > >>>>>>
> > > > >>>>>>> a {{figureCaption}} nested macro.
> > > > >>>>>>>>
> > > > >>>>>>>>>
> > > > >>>>>>>>>> BTW this raises a question, will you support WYSIWYG
> editing
> > > of
> > > > >>>>>>>>>>
> > > > >>>>>>>>> nested
> > > > >>>>>>
> > > > >>>>>>> macros?
> > > > >>>>>>>>
> > > > >>>>>>>>>
> > > > >>>>>>>>> Not for the moment.
> > > > >>>>>>>>>
> > > > >>>>>>>>> Simon
> > > > >>>>>>>>>
> > > > >>>>>>>>>>
> > > > >>>>>>>>>> Thanks
> > > > >>>>>>>>>> -Vincent
> > > > >>>>>>>>>>
> > > > >>>>>>>>>> Thanks,
> > > > >>>>>>>>>>> Simon
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>
> > > > >>>>>>>>>> [snip]
> > > > >>>>>>>>>>
> > > > >>>>>>>>>>
> > > > >>>>>>>>> --
> > > > >>>>>>>>> Simon Urli
> > > > >>>>>>>>> Software Engineer at XWiki SAS
> > > > >>>>>>>>> [hidden email]
> > > > >>>>>>>>> More about us at http://www.xwiki.com
> > > > >>>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>>> --
> > > > >>>>>>>> Thomas Mortagne
> > > > >>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>
> > > > >>>>>>
> > > > >>>>>> --
> > > > >>>>>> Thomas Mortagne
> > > > >>>>>>
> > > > >>>>>>
> > > > >>>> --
> > > > >>>> Simon Urli
> > > > >>>> Software Engineer at XWiki SAS
> > > > >>>> [hidden email]
> > > > >>>> More about us at http://www.xwiki.com
> > > > >>>>
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >> --
> > > > >> Simon Urli
> > > > >> Software Engineer at XWiki SAS
> > > > >> [hidden email]
> > > > >> More about us at http://www.xwiki.com
> > > > >>
> > > > >
> > > > >
> > >
> > >
> > >
> > > --
> > > Thomas Mortagne
> > >
>
>
>
> --
> Thomas Mortagne
>
12