Re: [xwiki-devs] Proposal for Macro inline edition

[Thomas Mortagne]

On Mon, Oct 15, 2018 at 10:48 AM Marius Dumitru Florea
 wrote:
>
> On Tue, Oct 9, 2018 at 3:22 PM Thomas Mortagne 
> wrote:
>
> > On Tue, Oct 9, 2018 at 1:53 PM Marius Dumitru Florea
> >  wrote:
> > >
> > > On Mon, Oct 8, 2018 at 11:20 AM Thomas Mortagne <
> > thomas.morta...@xwiki.com>
> > > wrote:
> > >
> > > > On Fri, Oct 5, 2018 at 6:05 PM Marius Dumitru Florea
> > > >  wrote:
> > > > >
> > > > > Thomas, I'm looking at how the editor can save the macro content
> > edited
> > > > > in-line and there are two options I think:
> > > > >
> > > > > (1) The editor does a separate request to a dedicated service to
> > convert
> > > > > the macro content from HTML, before the entire page content is saved
> > > > > (2) The editor marks the macro calls that need to be converted and
> > the
> > > > > conversion is done when the entire page content is converted
> > > > >
> > > > > I think the second option makes more sense. We already convert the
> > page
> > > > > content from HTML to wiki syntax. We could also convert the macro
> > content
> > > > > in the same flow, if needed.
> > > > >
> > > > > Note that we can't do the conversion of the macro content every time
> > the
> > > > > page content is converted. We need to convert the macro content from
> > HTML
> > > > > only if the editor says that is has been edited in-line. There are at
> > > > least
> > > > > 2 cases when the conversion is not needed:
> > > > >
> > > > > * when your insert a gadget in the dashboard (it uses the same Macro
> > > > Insert
> > > > > wizard from CKEditor)
> > > > > * when the macro outputs in-line content, since the CKEditor doesn't
> > > > > properly support editing in-line widgets in-place (see my other mail)
> > > > >
> > > > > So we need away to mark the macro calls that need conversion. The
> > macro
> > > > > marker supports only macro name, parameters and content. One idea is
> > to
> > > > use
> > > > > some "reserved" parameter, such as "__requiresHTMLConversion".
> > > > >
> > > > > WDYT?
> > > >
> > > > Yes +1 for (2), that's the safest and what makes the most sense anyway.
> > > >
> > > > For the marker I'm not a big fan of the parameter but hard to find a
> > > > retro compatible syntax otherwise (we should have put keywords in the
> > > > initial annotation syntax instead of just the ordered values...).
> > > >
> > > >
> > >
> > > > Now a marker is not enough, you also need to indicate the target
> > > > syntax (the html parser might now know it) in which it needs to be
> > > > converted.
> > >
> > >
> > > I was thinking that the parser (or some filter before the parser is
> > called)
> > > could use the SyntaxDescriptor component from
> > > https://github.com/xwiki/xwiki-rendering/pull/145/files to determine the
> > > target syntax for the macro content based on the macro parameters.
> > > Indicating the syntax in the macro call is OK as long as the syntax is
> > > static and the editor gets it from the meta data attributes. But if the
> > > content syntax depends on the macro parameters then the editor needs to
> > > make a request to compute the syntax each time the macro parameters are
> > > modified.
> >
> > SyntaxDescriptor is useless, knowing the macro won't give you the
> > syntax in many cases since you need the current syntax in a given
> > context. But yes for very standard macros this could be found in the
> > context and previous metadata blocks (provided the user did not
> > removed a metadata block by mistake, I guess the WYSIWYG could have
> > some protection against that).
> >
> > My point was more about future custom inline editors we talked about
> > for which it would be much easier if they can explicitly give the
> > information if there is a transformation need.
> >
> > >
> > > Also we need something which support parameters conversion
> > > > too since it's planned.
> > >
> > >
> > > I agree.
> > >
> > >
> > > > Finally I think I would prefer something even
> > > > more collision proof.
> > > >
> > > > For example:
> > > >
> > > > [[convert:__content]]=xwiki/2.1
> > > > param1="toto" [[convert:param1]]="xwiki/2.1"
> > > >
> > > > or
> > > >
> > > > [[convert:xwiki/2.1:__content]]="" ("" is just ignored, probably
> > > > better to make the html parser support not having a value at all which
> > > > might already be the case, I don't remember)
> > > > [[convert:xwiki/2.1:param1]]="toto"
> > > >
> > >
> > > Both look fine (with a slightly preference towards the first option) but
> > > I'm not convinced we need to specify the syntax. The parser has the macro
> > > call so it knows the macro and the parameter values so it could determine
> > > the syntax.
> >
> >
>
> > Anyway, I though about it a bit more and I think we don't need to
> > introduce anything in the macro annotation: the same metadata the
> > WYSIWYG is using to know that a content is editable could be used by
> > the HTML parser to know it should convert it instead of getting it
> > from the annotation. And this metadata is planned to 

Re: [xwiki-devs] Proposal for Macro inline edition

[Marius Dumitru Florea]

On Tue, Oct 9, 2018 at 3:22 PM Thomas Mortagne 
wrote:

> On Tue, Oct 9, 2018 at 1:53 PM Marius Dumitru Florea
>  wrote:
> >
> > On Mon, Oct 8, 2018 at 11:20 AM Thomas Mortagne <
> thomas.morta...@xwiki.com>
> > wrote:
> >
> > > On Fri, Oct 5, 2018 at 6:05 PM Marius Dumitru Florea
> > >  wrote:
> > > >
> > > > Thomas, I'm looking at how the editor can save the macro content
> edited
> > > > in-line and there are two options I think:
> > > >
> > > > (1) The editor does a separate request to a dedicated service to
> convert
> > > > the macro content from HTML, before the entire page content is saved
> > > > (2) The editor marks the macro calls that need to be converted and
> the
> > > > conversion is done when the entire page content is converted
> > > >
> > > > I think the second option makes more sense. We already convert the
> page
> > > > content from HTML to wiki syntax. We could also convert the macro
> content
> > > > in the same flow, if needed.
> > > >
> > > > Note that we can't do the conversion of the macro content every time
> the
> > > > page content is converted. We need to convert the macro content from
> HTML
> > > > only if the editor says that is has been edited in-line. There are at
> > > least
> > > > 2 cases when the conversion is not needed:
> > > >
> > > > * when your insert a gadget in the dashboard (it uses the same Macro
> > > Insert
> > > > wizard from CKEditor)
> > > > * when the macro outputs in-line content, since the CKEditor doesn't
> > > > properly support editing in-line widgets in-place (see my other mail)
> > > >
> > > > So we need away to mark the macro calls that need conversion. The
> macro
> > > > marker supports only macro name, parameters and content. One idea is
> to
> > > use
> > > > some "reserved" parameter, such as "__requiresHTMLConversion".
> > > >
> > > > WDYT?
> > >
> > > Yes +1 for (2), that's the safest and what makes the most sense anyway.
> > >
> > > For the marker I'm not a big fan of the parameter but hard to find a
> > > retro compatible syntax otherwise (we should have put keywords in the
> > > initial annotation syntax instead of just the ordered values...).
> > >
> > >
> >
> > > Now a marker is not enough, you also need to indicate the target
> > > syntax (the html parser might now know it) in which it needs to be
> > > converted.
> >
> >
> > I was thinking that the parser (or some filter before the parser is
> called)
> > could use the SyntaxDescriptor component from
> > https://github.com/xwiki/xwiki-rendering/pull/145/files to determine the
> > target syntax for the macro content based on the macro parameters.
> > Indicating the syntax in the macro call is OK as long as the syntax is
> > static and the editor gets it from the meta data attributes. But if the
> > content syntax depends on the macro parameters then the editor needs to
> > make a request to compute the syntax each time the macro parameters are
> > modified.
>
> SyntaxDescriptor is useless, knowing the macro won't give you the
> syntax in many cases since you need the current syntax in a given
> context. But yes for very standard macros this could be found in the
> context and previous metadata blocks (provided the user did not
> removed a metadata block by mistake, I guess the WYSIWYG could have
> some protection against that).
>
> My point was more about future custom inline editors we talked about
> for which it would be much easier if they can explicitly give the
> information if there is a transformation need.
>
> >
> > Also we need something which support parameters conversion
> > > too since it's planned.
> >
> >
> > I agree.
> >
> >
> > > Finally I think I would prefer something even
> > > more collision proof.
> > >
> > > For example:
> > >
> > > [[convert:__content]]=xwiki/2.1
> > > param1="toto" [[convert:param1]]="xwiki/2.1"
> > >
> > > or
> > >
> > > [[convert:xwiki/2.1:__content]]="" ("" is just ignored, probably
> > > better to make the html parser support not having a value at all which
> > > might already be the case, I don't remember)
> > > [[convert:xwiki/2.1:param1]]="toto"
> > >
> >
> > Both look fine (with a slightly preference towards the first option) but
> > I'm not convinced we need to specify the syntax. The parser has the macro
> > call so it knows the macro and the parameter values so it could determine
> > the syntax.
>
>

> Anyway, I though about it a bit more and I think we don't need to
> introduce anything in the macro annotation: the same metadata the
> WYSIWYG is using to know that a content is editable could be used by
> the HTML parser to know it should convert it instead of getting it
> from the annotation. And this metadata is planned to support
> parameters too. It also cover future custom editors need since there
> is a metadata for the syntax.
>

ATM the WYSIWYG editor sends back *only* the macro markers. The macro
output is simply ignored on save because up until now all the information
that was needed was available in the macro marker so 

Re: [xwiki-devs] Proposal for Macro inline edition

[Thomas Mortagne]

On Tue, Oct 9, 2018 at 1:53 PM Marius Dumitru Florea
 wrote:
>
> On Mon, Oct 8, 2018 at 11:20 AM Thomas Mortagne 
> wrote:
>
> > On Fri, Oct 5, 2018 at 6:05 PM Marius Dumitru Florea
> >  wrote:
> > >
> > > Thomas, I'm looking at how the editor can save the macro content edited
> > > in-line and there are two options I think:
> > >
> > > (1) The editor does a separate request to a dedicated service to convert
> > > the macro content from HTML, before the entire page content is saved
> > > (2) The editor marks the macro calls that need to be converted and the
> > > conversion is done when the entire page content is converted
> > >
> > > I think the second option makes more sense. We already convert the page
> > > content from HTML to wiki syntax. We could also convert the macro content
> > > in the same flow, if needed.
> > >
> > > Note that we can't do the conversion of the macro content every time the
> > > page content is converted. We need to convert the macro content from HTML
> > > only if the editor says that is has been edited in-line. There are at
> > least
> > > 2 cases when the conversion is not needed:
> > >
> > > * when your insert a gadget in the dashboard (it uses the same Macro
> > Insert
> > > wizard from CKEditor)
> > > * when the macro outputs in-line content, since the CKEditor doesn't
> > > properly support editing in-line widgets in-place (see my other mail)
> > >
> > > So we need away to mark the macro calls that need conversion. The macro
> > > marker supports only macro name, parameters and content. One idea is to
> > use
> > > some "reserved" parameter, such as "__requiresHTMLConversion".
> > >
> > > WDYT?
> >
> > Yes +1 for (2), that's the safest and what makes the most sense anyway.
> >
> > For the marker I'm not a big fan of the parameter but hard to find a
> > retro compatible syntax otherwise (we should have put keywords in the
> > initial annotation syntax instead of just the ordered values...).
> >
> >
>
> > Now a marker is not enough, you also need to indicate the target
> > syntax (the html parser might now know it) in which it needs to be
> > converted.
>
>
> I was thinking that the parser (or some filter before the parser is called)
> could use the SyntaxDescriptor component from
> https://github.com/xwiki/xwiki-rendering/pull/145/files to determine the
> target syntax for the macro content based on the macro parameters.
> Indicating the syntax in the macro call is OK as long as the syntax is
> static and the editor gets it from the meta data attributes. But if the
> content syntax depends on the macro parameters then the editor needs to
> make a request to compute the syntax each time the macro parameters are
> modified.

SyntaxDescriptor is useless, knowing the macro won't give you the
syntax in many cases since you need the current syntax in a given
context. But yes for very standard macros this could be found in the
context and previous metadata blocks (provided the user did not
removed a metadata block by mistake, I guess the WYSIWYG could have
some protection against that).

My point was more about future custom inline editors we talked about
for which it would be much easier if they can explicitly give the
information if there is a transformation need.

>
> Also we need something which support parameters conversion
> > too since it's planned.
>
>
> I agree.
>
>
> > Finally I think I would prefer something even
> > more collision proof.
> >
> > For example:
> >
> > [[convert:__content]]=xwiki/2.1
> > param1="toto" [[convert:param1]]="xwiki/2.1"
> >
> > or
> >
> > [[convert:xwiki/2.1:__content]]="" ("" is just ignored, probably
> > better to make the html parser support not having a value at all which
> > might already be the case, I don't remember)
> > [[convert:xwiki/2.1:param1]]="toto"
> >
>
> Both look fine (with a slightly preference towards the first option) but
> I'm not convinced we need to specify the syntax. The parser has the macro
> call so it knows the macro and the parameter values so it could determine
> the syntax.

Anyway, I though about it a bit more and I think we don't need to
introduce anything in the macro annotation: the same metadata the
WYSIWYG is using to know that a content is editable could be used by
the HTML parser to know it should convert it instead of getting it
from the annotation. And this metadata is planned to support
parameters too. It also cover future custom editors need since there
is a metadata for the syntax.

>
>
> >
> > >
> > > On Wed, Oct 3, 2018 at 6:42 PM Marius Dumitru Florea <
> > > mariusdumitru.flo...@xwiki.com> wrote:
> > >
> > > > Hi everyone,
> > > >
> > > > I've started implementing this on the WYSIWYG editor side and there are
> > > > two constraints that we need to be aware:
> > > >
> > > >
> > > > (1) Macro#supportsInlineMode() must be false
> > > >
> > > > The CKEditor handles macros as widgets
> > > > <
> > https://ckeditor.com/docs/ckeditor4/latest/guide/widget_sdk_intro.html>
> > > > and widgets can have 

Re: [xwiki-devs] Proposal for Macro inline edition

[Marius Dumitru Florea]

On Mon, Oct 8, 2018 at 11:20 AM Thomas Mortagne 
wrote:

> On Fri, Oct 5, 2018 at 6:05 PM Marius Dumitru Florea
>  wrote:
> >
> > Thomas, I'm looking at how the editor can save the macro content edited
> > in-line and there are two options I think:
> >
> > (1) The editor does a separate request to a dedicated service to convert
> > the macro content from HTML, before the entire page content is saved
> > (2) The editor marks the macro calls that need to be converted and the
> > conversion is done when the entire page content is converted
> >
> > I think the second option makes more sense. We already convert the page
> > content from HTML to wiki syntax. We could also convert the macro content
> > in the same flow, if needed.
> >
> > Note that we can't do the conversion of the macro content every time the
> > page content is converted. We need to convert the macro content from HTML
> > only if the editor says that is has been edited in-line. There are at
> least
> > 2 cases when the conversion is not needed:
> >
> > * when your insert a gadget in the dashboard (it uses the same Macro
> Insert
> > wizard from CKEditor)
> > * when the macro outputs in-line content, since the CKEditor doesn't
> > properly support editing in-line widgets in-place (see my other mail)
> >
> > So we need away to mark the macro calls that need conversion. The macro
> > marker supports only macro name, parameters and content. One idea is to
> use
> > some "reserved" parameter, such as "__requiresHTMLConversion".
> >
> > WDYT?
>
> Yes +1 for (2), that's the safest and what makes the most sense anyway.
>
> For the marker I'm not a big fan of the parameter but hard to find a
> retro compatible syntax otherwise (we should have put keywords in the
> initial annotation syntax instead of just the ordered values...).
>
>

> Now a marker is not enough, you also need to indicate the target
> syntax (the html parser might now know it) in which it needs to be
> converted.


I was thinking that the parser (or some filter before the parser is called)
could use the SyntaxDescriptor component from
https://github.com/xwiki/xwiki-rendering/pull/145/files to determine the
target syntax for the macro content based on the macro parameters.
Indicating the syntax in the macro call is OK as long as the syntax is
static and the editor gets it from the meta data attributes. But if the
content syntax depends on the macro parameters then the editor needs to
make a request to compute the syntax each time the macro parameters are
modified.

Also we need something which support parameters conversion
> too since it's planned.


I agree.


> Finally I think I would prefer something even
> more collision proof.
>
> For example:
>
> [[convert:__content]]=xwiki/2.1
> param1="toto" [[convert:param1]]="xwiki/2.1"
>
> or
>
> [[convert:xwiki/2.1:__content]]="" ("" is just ignored, probably
> better to make the html parser support not having a value at all which
> might already be the case, I don't remember)
> [[convert:xwiki/2.1:param1]]="toto"
>

Both look fine (with a slightly preference towards the first option) but
I'm not convinced we need to specify the syntax. The parser has the macro
call so it knows the macro and the parameter values so it could determine
the syntax.


>
> >
> > On Wed, Oct 3, 2018 at 6:42 PM Marius Dumitru Florea <
> > mariusdumitru.flo...@xwiki.com> wrote:
> >
> > > Hi everyone,
> > >
> > > I've started implementing this on the WYSIWYG editor side and there are
> > > two constraints that we need to be aware:
> > >
> > >
> > > (1) Macro#supportsInlineMode() must be false
> > >
> > > The CKEditor handles macros as widgets
> > > <
> https://ckeditor.com/docs/ckeditor4/latest/guide/widget_sdk_intro.html>
> > > and widgets can have nested editable parts, which is great, BUT these
> > > nested editable parts must have a block-level element as parent. The
> list
> > > of elements that are accepted as in place editing hosts can be found
> here
> > >
> https://ckeditor.com/docs/ckeditor4/latest/api/CKEDITOR_dtd.html#property-S-editable
> > > . This means that only block-level widgets can be edited in place. As a
> > > consequence, only block-level macros can be edited in place. There's an
> > > open issue about this
> https://github.com/ckeditor/ckeditor-dev/issues/1091
> > > but I can't tell if it's going to be fixed soon or not.
> > >
> > > What options do we have?
> > >
> > > (a) enable in place editing only for macros that have
> supportsInlineMode
> > > false; that's the easiest but it excludes from the start macros such as
> > > info, error, warning, which is a pity.
> > > (b) activate in place editing only when the macro generates block level
> > > content; this means that the users will be able to edit in place a
> warning
> > > macro that is standalone, such as:
> > >
> > > -8<-
> > > before
> > >
> > > {{warning}}message{{/warning}}
> > >
> > > after
> > > ->8-
> > >
> > > but not a warning macro that is inside some paragraph te

Re: [xwiki-devs] Proposal for Macro inline edition

[Thomas Mortagne]

On Fri, Oct 5, 2018 at 6:05 PM Marius Dumitru Florea
 wrote:
>
> Thomas, I'm looking at how the editor can save the macro content edited
> in-line and there are two options I think:
>
> (1) The editor does a separate request to a dedicated service to convert
> the macro content from HTML, before the entire page content is saved
> (2) The editor marks the macro calls that need to be converted and the
> conversion is done when the entire page content is converted
>
> I think the second option makes more sense. We already convert the page
> content from HTML to wiki syntax. We could also convert the macro content
> in the same flow, if needed.
>
> Note that we can't do the conversion of the macro content every time the
> page content is converted. We need to convert the macro content from HTML
> only if the editor says that is has been edited in-line. There are at least
> 2 cases when the conversion is not needed:
>
> * when your insert a gadget in the dashboard (it uses the same Macro Insert
> wizard from CKEditor)
> * when the macro outputs in-line content, since the CKEditor doesn't
> properly support editing in-line widgets in-place (see my other mail)
>
> So we need away to mark the macro calls that need conversion. The macro
> marker supports only macro name, parameters and content. One idea is to use
> some "reserved" parameter, such as "__requiresHTMLConversion".
>
> WDYT?

Yes +1 for (2), that's the safest and what makes the most sense anyway.

For the marker I'm not a big fan of the parameter but hard to find a
retro compatible syntax otherwise (we should have put keywords in the
initial annotation syntax instead of just the ordered values...).

Now a marker is not enough, you also need to indicate the target
syntax (the html parser might now know it) in which it needs to be
converted. Also we need something which support parameters conversion
too since it's planned. Finally I think I would prefer something even
more collision proof.

For example:

[[convert:__content]]=xwiki/2.1
param1="toto" [[convert:param1]]="xwiki/2.1"

or

[[convert:xwiki/2.1:__content]]="" ("" is just ignored, probably
better to make the html parser support not having a value at all which
might already be the case, I don't remember)
[[convert:xwiki/2.1:param1]]="toto"

>
> On Wed, Oct 3, 2018 at 6:42 PM Marius Dumitru Florea <
> mariusdumitru.flo...@xwiki.com> wrote:
>
> > Hi everyone,
> >
> > I've started implementing this on the WYSIWYG editor side and there are
> > two constraints that we need to be aware:
> >
> >
> > (1) Macro#supportsInlineMode() must be false
> >
> > The CKEditor handles macros as widgets
> > 
> > and widgets can have nested editable parts, which is great, BUT these
> > nested editable parts must have a block-level element as parent. The list
> > of elements that are accepted as in place editing hosts can be found here
> > https://ckeditor.com/docs/ckeditor4/latest/api/CKEDITOR_dtd.html#property-S-editable
> > . This means that only block-level widgets can be edited in place. As a
> > consequence, only block-level macros can be edited in place. There's an
> > open issue about this https://github.com/ckeditor/ckeditor-dev/issues/1091
> > but I can't tell if it's going to be fixed soon or not.
> >
> > What options do we have?
> >
> > (a) enable in place editing only for macros that have supportsInlineMode
> > false; that's the easiest but it excludes from the start macros such as
> > info, error, warning, which is a pity.
> > (b) activate in place editing only when the macro generates block level
> > content; this means that the users will be able to edit in place a warning
> > macro that is standalone, such as:
> >
> > -8<-
> > before
> >
> > {{warning}}message{{/warning}}
> >
> > after
> > ->8-
> >
> > but not a warning macro that is inside some paragraph text, such as:
> >
> > -8<-
> > before {{warning}}message{{/warning}} after
> > ->8-
> >
> > The issue is that we don't always know if the macro output is block-level
> > until we render the macro so hiding the macro content text area when
> > inserting a macro is not easy.
> >
> > (c) Try to implement https://github.com/ckeditor/ckeditor-dev/issues/1091
> > ourselves, but I don't think it's easy
> > (d) Don't use widgets to support macros and implement something custom. I
> > think this is crazy.
> >
> >
> > (2) The second constraint is that the macro content must not be mandatory.
> >
> > ATM both {{info/}} and {{info}}{{/info}} generate "The required content is
> > missing." and so do the other macros I've tested. So it seems there's no
> > distinction between empty content and no content at the implementation
> > level. Thus, if we want to hide the macro content text area when inserting
> > a macro such as {{info}} then we need to make the macro content optional.
> > Either by changing the macro descriptor or by changing the implementation
> > to

Re: [xwiki-devs] Proposal for Macro inline edition

[Marius Dumitru Florea]

Thomas, I'm looking at how the editor can save the macro content edited
in-line and there are two options I think:

(1) The editor does a separate request to a dedicated service to convert
the macro content from HTML, before the entire page content is saved
(2) The editor marks the macro calls that need to be converted and the
conversion is done when the entire page content is converted

I think the second option makes more sense. We already convert the page
content from HTML to wiki syntax. We could also convert the macro content
in the same flow, if needed.

Note that we can't do the conversion of the macro content every time the
page content is converted. We need to convert the macro content from HTML
only if the editor says that is has been edited in-line. There are at least
2 cases when the conversion is not needed:

* when your insert a gadget in the dashboard (it uses the same Macro Insert
wizard from CKEditor)
* when the macro outputs in-line content, since the CKEditor doesn't
properly support editing in-line widgets in-place (see my other mail)

So we need away to mark the macro calls that need conversion. The macro
marker supports only macro name, parameters and content. One idea is to use
some "reserved" parameter, such as "__requiresHTMLConversion".

WDYT?

On Wed, Oct 3, 2018 at 6:42 PM Marius Dumitru Florea <
mariusdumitru.flo...@xwiki.com> wrote:

> Hi everyone,
>
> I've started implementing this on the WYSIWYG editor side and there are
> two constraints that we need to be aware:
>
>
> (1) Macro#supportsInlineMode() must be false
>
> The CKEditor handles macros as widgets
> 
> and widgets can have nested editable parts, which is great, BUT these
> nested editable parts must have a block-level element as parent. The list
> of elements that are accepted as in place editing hosts can be found here
> https://ckeditor.com/docs/ckeditor4/latest/api/CKEDITOR_dtd.html#property-S-editable
> . This means that only block-level widgets can be edited in place. As a
> consequence, only block-level macros can be edited in place. There's an
> open issue about this https://github.com/ckeditor/ckeditor-dev/issues/1091
> but I can't tell if it's going to be fixed soon or not.
>
> What options do we have?
>
> (a) enable in place editing only for macros that have supportsInlineMode
> false; that's the easiest but it excludes from the start macros such as
> info, error, warning, which is a pity.
> (b) activate in place editing only when the macro generates block level
> content; this means that the users will be able to edit in place a warning
> macro that is standalone, such as:
>
> -8<-
> before
>
> {{warning}}message{{/warning}}
>
> after
> ->8-
>
> but not a warning macro that is inside some paragraph text, such as:
>
> -8<-
> before {{warning}}message{{/warning}} after
> ->8-
>
> The issue is that we don't always know if the macro output is block-level
> until we render the macro so hiding the macro content text area when
> inserting a macro is not easy.
>
> (c) Try to implement https://github.com/ckeditor/ckeditor-dev/issues/1091
> ourselves, but I don't think it's easy
> (d) Don't use widgets to support macros and implement something custom. I
> think this is crazy.
>
>
> (2) The second constraint is that the macro content must not be mandatory.
>
> ATM both {{info/}} and {{info}}{{/info}} generate "The required content is
> missing." and so do the other macros I've tested. So it seems there's no
> distinction between empty content and no content at the implementation
> level. Thus, if we want to hide the macro content text area when inserting
> a macro such as {{info}} then we need to make the macro content optional.
> Either by changing the macro descriptor or by changing the implementation
> to differentiate the empty content from no content specified.
>
> Thanks,
> Marius
>
>
> On Mon, Sep 10, 2018 at 2:05 PM Simon Urli  wrote:
>
>> 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:
>>
>> 
>>
>>  
>>  some title
>>
>>Some content
>> 
>>
>> 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.:
>>
>> 
>>
>>  
>>  some title
>>
>>Some content
>> 
>>
>> 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 pa

Re: [xwiki-devs] Proposal for Macro inline edition

[Simon Urli]

Hi everyone,

On 10/3/18 5:42 PM, Marius Dumitru Florea wrote:

Hi everyone,

I've started implementing this on the WYSIWYG editor side and there are two
constraints that we need to be aware:


(1) Macro#supportsInlineMode() must be false

The CKEditor handles macros as widgets

and widgets can have nested editable parts, which is great, BUT these
nested editable parts must have a block-level element as parent. The list
of elements that are accepted as in place editing hosts can be found here
https://ckeditor.com/docs/ckeditor4/latest/api/CKEDITOR_dtd.html#property-S-editable
. This means that only block-level widgets can be edited in place. As a
consequence, only block-level macros can be edited in place. There's an
open issue about this https://github.com/ckeditor/ckeditor-dev/issues/1091
but I can't tell if it's going to be fixed soon or not.

What options do we have?

(a) enable in place editing only for macros that have supportsInlineMode
false; that's the easiest but it excludes from the start macros such as
info, error, warning, which is a pity.
(b) activate in place editing only when the macro generates block level
content; this means that the users will be able to edit in place a warning
macro that is standalone, such as:

-8<-
before

{{warning}}message{{/warning}}

after
->8-

but not a warning macro that is inside some paragraph text, such as:

-8<-
before {{warning}}message{{/warning}} after
->8-

The issue is that we don't always know if the macro output is block-level
until we render the macro so hiding the macro content text area when
inserting a macro is not easy.


This option seems less limitating and more easy to achieve isn't it?
And it seems to me that the limitation you mention, can be mitigated if 
the content is optional: as you specify below even without a content, 
the macro message is able to produce an XDOM output that you could use 
to know if the top level is a block or not.




(c) Try to implement https://github.com/ckeditor/ckeditor-dev/issues/1091
ourselves, but I don't think it's easy
(d) Don't use widgets to support macros and implement something custom. I
think this is crazy.


(2) The second constraint is that the macro content must not be mandatory.

ATM both {{info/}} and {{info}}{{/info}} generate "The required content is
missing." and so do the other macros I've tested. So it seems there's no
distinction between empty content and no content at the implementation
level. Thus, if we want to hide the macro content text area when inserting
a macro such as {{info}} then we need to make the macro content optional.
Either by changing the macro descriptor or by changing the implementation
to differentiate the empty content from no content specified.


Making the macro content means in fact that there is a default content. 
So if we make the content optional for the message macro, do you propose 
that we put an empty default content?


Simon


Thanks,
Marius


On Mon, Sep 10, 2018 at 2:05 PM Simon Urli  wrote:


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:



  
  some title

Some content


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



  
  some title

Some content


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:

my foo parameter
value

However I don't know right now how the editor would manage cases such as:
Some content with a
parameter

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
simon.u...@xwiki.com
More about us at http://www.xwiki.com



--
Simon Urli
Software Engineer at XWiki SAS
simon.u...@xwiki.com
More about us at http://www.xwiki.com

Re: [xwiki-devs] Proposal for Macro inline edition

[Marius Dumitru Florea]

Hi everyone,

I've started implementing this on the WYSIWYG editor side and there are two
constraints that we need to be aware:


(1) Macro#supportsInlineMode() must be false

The CKEditor handles macros as widgets

and widgets can have nested editable parts, which is great, BUT these
nested editable parts must have a block-level element as parent. The list
of elements that are accepted as in place editing hosts can be found here
https://ckeditor.com/docs/ckeditor4/latest/api/CKEDITOR_dtd.html#property-S-editable
. This means that only block-level widgets can be edited in place. As a
consequence, only block-level macros can be edited in place. There's an
open issue about this https://github.com/ckeditor/ckeditor-dev/issues/1091
but I can't tell if it's going to be fixed soon or not.

What options do we have?

(a) enable in place editing only for macros that have supportsInlineMode
false; that's the easiest but it excludes from the start macros such as
info, error, warning, which is a pity.
(b) activate in place editing only when the macro generates block level
content; this means that the users will be able to edit in place a warning
macro that is standalone, such as:

-8<-
before

{{warning}}message{{/warning}}

after
->8-

but not a warning macro that is inside some paragraph text, such as:

-8<-
before {{warning}}message{{/warning}} after
->8-

The issue is that we don't always know if the macro output is block-level
until we render the macro so hiding the macro content text area when
inserting a macro is not easy.

(c) Try to implement https://github.com/ckeditor/ckeditor-dev/issues/1091
ourselves, but I don't think it's easy
(d) Don't use widgets to support macros and implement something custom. I
think this is crazy.


(2) The second constraint is that the macro content must not be mandatory.

ATM both {{info/}} and {{info}}{{/info}} generate "The required content is
missing." and so do the other macros I've tested. So it seems there's no
distinction between empty content and no content at the implementation
level. Thus, if we want to hide the macro content text area when inserting
a macro such as {{info}} then we need to make the macro content optional.
Either by changing the macro descriptor or by changing the implementation
to differentiate the empty content from no content specified.

Thanks,
Marius


On Mon, Sep 10, 2018 at 2:05 PM Simon Urli  wrote:

> 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:
>
> 
>
>  
>  some title
>
>Some content
> 
>
> 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.:
>
> 
>
>  
>  some title
>
>Some content
> 
>
> 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:
>
> my foo parameter
> value
>
> However I don't know right now how the editor would manage cases such as:
> Some content with  class="editable-content" data-parameter="myparameter">a
> parameter
>
> 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
> simon.u...@xwiki.com
> More about us at http://www.xwiki.com
>

Re: [xwiki-devs] Proposal for Macro inline edition

[Vincent Massol]

Hi Thomas and all,

> On 17 Sep 2018, at 12:22, Thomas Mortagne  wrote:
> 
> On Mon, Sep 17, 2018 at 9:52 AM Vincent Massol  wrote:
>> 
>> Hi Simon and all,
>> 
>> After thinking about this (and not being to sleep one night for some hours 
>> about it ;)), I have the following problems with the proposal so far:
>> * It doesn’t address macro content types that are NOT in the current 
>> document’s syntax.
>> * The API is awkward since the proposal is to return a List java Type 
>> for "macros having content written in the current document’s syntax”, while 
>> other macros containing markup would need to invent their own types.
>> 
>> Needs:
>> =
>> 
>> There are 2 use cases for this:
>> 
>> A) Dynamic macro content type.
>> 
>> Just giving 2 existing examples:
>> 
>> Example 1: {{content syntax=“markdown/1.2”}}….{{/content}}
>> Example 2: {{jira source=“jql | list”…}}…{{/jira}}
>> 
>> The content types depends on some macro parameter values in each case.
>> 
>> B) Fixed content type
>> 
>> Example: Someone contributes a new macro in xwiki-contrib named {{markdown}} 
>> and that contains a fixed markup content in syntax “markdown/1.2”.
>> 
>> Issues
>> =
>> 
>> The current proposal says that macro not having content written in the 
>> current document’s syntax should implement their own content Type.
>> 
>> However there are several problems with that:
>> * It gives an uneven API: it’s not normal to not return List type for 
>> any macro having markup that can be parsed into a List.
>> * It means the WYSIWYG editor won’t be able to support the {{content}} or 
>> {{markdown}} macros I mentioned above which is a pity since technically it 
>> can support them when there are parsers/renderers for the syntax. Thomas 
>> mentioned (during a conf call) that we could simply add support for those 
>> special types in the WYSIWYG by hardcoding them. However that won’t work 
>> since my example with the {{markdown}} macros is about a contrib macro that 
>> doesn’t exist ATM so we cannot hardcode its support in the WYSIWYG.
> 
> No this is not what I said. I said that the WYSIWYG can support
> several types and I gave an example of Type which would cover the
> content macro use case: a type which extends Block or List and
> for which the WYSIWYG knows the syntax come from a parameter named
> "syntax". Many unknown macros can use the same type, nothing do with
> the macro with id "content”.

So you’re actually confirming that what I had understood you said was correct :)

With your design, the WYSIWYG cannot support the use case of a contrib 
extension being added and specifying the syntax through some parameter (you 
cannot guess the parameter name obviously and the contrib developer is free to 
use whatever name makes sense to him) or some other conditions.

Constraining the WYSIWYG to only support macros have a parameter named “syntax” 
is bad ofc.

It also wouldn’t support the other use case I gave, which is a macro that has a 
fixed content type (that doesn’t come from a “syntax” parameter) such as a 
{{markdown}} macro that I mentioned.

So with your design the WYSIWYG cannot support all cases that it could support, 
which is the case in the design that I proposed.

> An idea I did not mentioned during the
> meeting is that we could even decide the parameter "syntax" with type
> "Syntax" is a standard way to overwrite current syntax for any macro
> which expose it in which case this behavior would simply be associated
> to List Type (and taken into account in MacroContentParser).

What would this mean for a user contributing a {{markdown}} macro? That he’d 
have to define a optional parameter named “syntax”, and that this parameter 
would need to have some @Hidden annotation to be hidden from the WYSIWYG 
editor? 

Seems this would mix semantics. Unless I’ve misunderstood it, I prefer the 
solution I’ve proposed so far.

> As for jira macro I did not really mentioned it since it was not
> really a priority for the first version which is targeting more macros
> containing wiki content we can edit directly in the WYSIWYG

It’s not about implementing anything now but to have a design that supports it.

> but for me
> it would be a dedicated type and associated editor.

How would the custom editor now which format it’s written in (JQL or List of 
JIRA IDs)? You have exactly the same type of issue than for the WYSIWYG where 
the Type is not enough and you need additional information (the Syntax for the 
WYSIWYG).

Thanks
-Vincent

> 
>> 
>> Proposal
>> ===
>> 
>> Thus I really believe that we need to do 2 things:
>> 1) Have the macro content’s getType() return the java type that can 
>> represent the content, i.e. List whenever the content contains markup 
>> that can be parsed into a List by one syntax parser. And have 
>> List simply means markup content.
>> 2) Have the WYSIWYG be able to edit inline macros having markup content, 
>> i.e. that returns a List type, when they are written in a supported 
>> s

Re: [xwiki-devs] Proposal for Macro inline edition

[Thomas Mortagne]

On Mon, Sep 17, 2018 at 9:52 AM Vincent Massol  wrote:
>
> Hi Simon and all,
>
> After thinking about this (and not being to sleep one night for some hours 
> about it ;)), I have the following problems with the proposal so far:
> * It doesn’t address macro content types that are NOT in the current 
> document’s syntax.
> * The API is awkward since the proposal is to return a List java Type 
> for "macros having content written in the current document’s syntax”, while 
> other macros containing markup would need to invent their own types.
>
> Needs:
> =
>
> There are 2 use cases for this:
>
> A) Dynamic macro content type.
>
> Just giving 2 existing examples:
>
> Example 1: {{content syntax=“markdown/1.2”}}….{{/content}}
> Example 2: {{jira source=“jql | list”…}}…{{/jira}}
>
> The content types depends on some macro parameter values in each case.
>
> B) Fixed content type
>
> Example: Someone contributes a new macro in xwiki-contrib named {{markdown}} 
> and that contains a fixed markup content in syntax “markdown/1.2”.
>
> Issues
> =
>
> The current proposal says that macro not having content written in the 
> current document’s syntax should implement their own content Type.
>
> However there are several problems with that:
> * It gives an uneven API: it’s not normal to not return List type for 
> any macro having markup that can be parsed into a List.
> * It means the WYSIWYG editor won’t be able to support the {{content}} or 
> {{markdown}} macros I mentioned above which is a pity since technically it 
> can support them when there are parsers/renderers for the syntax. Thomas 
> mentioned (during a conf call) that we could simply add support for those 
> special types in the WYSIWYG by hardcoding them. However that won’t work 
> since my example with the {{markdown}} macros is about a contrib macro that 
> doesn’t exist ATM so we cannot hardcode its support in the WYSIWYG.

No this is not what I said. I said that the WYSIWYG can support
several types and I gave an example of Type which would cover the
content macro use case: a type which extends Block or List and
for which the WYSIWYG knows the syntax come from a parameter named
"syntax". Many unknown macros can use the same type, nothing do with
the macro with id "content". An idea I did not mentioned during the
meeting is that we could even decide the parameter "syntax" with type
"Syntax" is a standard way to overwrite current syntax for any macro
which expose it in which case this behavior would simply be associated
to List Type (and taken into account in MacroContentParser).

As for jira macro I did not really mentioned it since it was not
really a priority for the first version which is targeting more macros
containing wiki content we can edit directly in the WYSIWYG but for me
it would be a dedicated type and associated editor.

>
> Proposal
> ===
>
> Thus I really believe that we need to do 2 things:
> 1) Have the macro content’s getType() return the java type that can represent 
> the content, i.e. List whenever the content contains markup that can 
> be parsed into a List by one syntax parser. And have List 
> simply means markup content.
> 2) Have the WYSIWYG be able to edit inline macros having markup content, i.e. 
> that returns a List type, when they are written in a supported syntax 
> (a supported syntax is simply a syntax for which there’s a parser and a 
> renderer). Thus we need to have Macros be able to provide the Syntax to the 
> WYSIWYG.
>
> There are several ways to implement 2), one simple way is to introduce a 
> SyntaxDescriptor component role:
>
> @Role
> public interface SyntaxDescriptor
> {
> Syntax getSyntax(Map macroParameters);
> }
>
> And then have the WYSIWYG get a component instance of an implementation of 
> SyntaxDescriptor with a hint being the macro id for example. And if none is 
> found, default to a CurrentDocumentSyntaxDescriptor() that would return the 
> current document’s syntax. Or something like this.
>
> This also means that in the WYSIWYG macro dialog box, when a parameter is 
> modified, it would call SyntaxDescriptor#getSyntax() to get the Syntax and if 
> that syntax doesn’t have a parser/renderer, it would display the content in 
> the dialog box, as plain text.
>
> Planning
> ===
>
> We could imagine implementing this in 2 steps if we think it’s too much for 1 
> step. Step 1 would mean only supporting macro content in the current doc’s 
> syntax (as in the current proposal prior to this one in this email). Step 2 
> would mean breaking backward-compatibility (but getType() is @Unstable so we 
> would have over 1 year to do it) and implementing support for all cases.
>
> WDYT?
>
> Thanks
> -Vincent
>
> > On 14 Sep 2018, at 16:39, Simon Urli  wrote:
> >
> > Hi everyone,
> >
> > I just edited the design page of the proposal after the meeting we had 
> > yesterday with Vincent, Thomas and Marius: 
> > https://design.xwiki.org/xwiki/bin/view/Main/MacroInlineEditingContent/
> >
> > 

Re: [xwiki-devs] Proposal for Macro inline edition

[Vincent Massol]

Hi Simon and all,

After thinking about this (and not being to sleep one night for some hours 
about it ;)), I have the following problems with the proposal so far:
* It doesn’t address macro content types that are NOT in the current document’s 
syntax. 
* The API is awkward since the proposal is to return a List java Type 
for "macros having content written in the current document’s syntax”, while 
other macros containing markup would need to invent their own types.

Needs:
=

There are 2 use cases for this:

A) Dynamic macro content type. 

Just giving 2 existing examples:

Example 1: {{content syntax=“markdown/1.2”}}….{{/content}}
Example 2: {{jira source=“jql | list”…}}…{{/jira}}

The content types depends on some macro parameter values in each case.

B) Fixed content type

Example: Someone contributes a new macro in xwiki-contrib named {{markdown}} 
and that contains a fixed markup content in syntax “markdown/1.2”.

Issues
=

The current proposal says that macro not having content written in the current 
document’s syntax should implement their own content Type.

However there are several problems with that:
* It gives an uneven API: it’s not normal to not return List type for 
any macro having markup that can be parsed into a List.
* It means the WYSIWYG editor won’t be able to support the {{content}} or 
{{markdown}} macros I mentioned above which is a pity since technically it can 
support them when there are parsers/renderers for the syntax. Thomas mentioned 
(during a conf call) that we could simply add support for those special types 
in the WYSIWYG by hardcoding them. However that won’t work since my example 
with the {{markdown}} macros is about a contrib macro that doesn’t exist ATM so 
we cannot hardcode its support in the WYSIWYG.

Proposal
===

Thus I really believe that we need to do 2 things:
1) Have the macro content’s getType() return the java type that can represent 
the content, i.e. List whenever the content contains markup that can be 
parsed into a List by one syntax parser. And have List simply 
means markup content.
2) Have the WYSIWYG be able to edit inline macros having markup content, i.e. 
that returns a List type, when they are written in a supported syntax (a 
supported syntax is simply a syntax for which there’s a parser and a renderer). 
Thus we need to have Macros be able to provide the Syntax to the WYSIWYG.

There are several ways to implement 2), one simple way is to introduce a 
SyntaxDescriptor component role:

@Role
public interface SyntaxDescriptor
{
Syntax getSyntax(Map macroParameters);
}

And then have the WYSIWYG get a component instance of an implementation of 
SyntaxDescriptor with a hint being the macro id for example. And if none is 
found, default to a CurrentDocumentSyntaxDescriptor() that would return the 
current document’s syntax. Or something like this.

This also means that in the WYSIWYG macro dialog box, when a parameter is 
modified, it would call SyntaxDescriptor#getSyntax() to get the Syntax and if 
that syntax doesn’t have a parser/renderer, it would display the content in the 
dialog box, as plain text.

Planning
===

We could imagine implementing this in 2 steps if we think it’s too much for 1 
step. Step 1 would mean only supporting macro content in the current doc’s 
syntax (as in the current proposal prior to this one in this email). Step 2 
would mean breaking backward-compatibility (but getType() is @Unstable so we 
would have over 1 year to do it) and implementing support for all cases.

WDYT?

Thanks
-Vincent

> On 14 Sep 2018, at 16:39, Simon Urli  wrote:
> 
> Hi everyone,
> 
> I just edited the design page of the proposal after the meeting we had 
> yesterday with Vincent, Thomas and Marius: 
> https://design.xwiki.org/xwiki/bin/view/Main/MacroInlineEditingContent/
> 
> To quickly sum up the main parts are:
>  - we allow to specify a type in the ContentDescriptor of the macro
>  - we define a new MetaDataBlock for Java macro to specify which part of the 
> content is editable
>  - we document a new attribute for GroupBlock/FormatBlock to specify which 
> part of the content is editable in WikiMacro
> 
> Thanks again for your feedbacks!
> Simon
> 
> On 9/12/18 6:46 PM, Thomas Mortagne wrote:
>> On Wed, Sep 12, 2018 at 5:56 PM Simon Urli  wrote:
>>> 
>>> 
>>> 
>>> On 9/12/18 5:45 PM, Thomas Mortagne wrote:
 Yeah I know, too many answer mails...
 
 On Wed, Sep 12, 2018 at 5:28 PM Thomas Mortagne
  wrote:
> 
> On Wed, Sep 12, 2018 at 5:07 PM Simon Urli  wrote:
>> 
>> 
>> 
>> On 9/12/18 5:02 PM, Marius Dumitru Florea wrote:
>>> On Wed, Sep 12, 2018 at 5:18 PM, Simon Urli  
>>> 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 

Re: [xwiki-devs] Proposal for Macro inline edition

[Simon Urli]

Hi everyone,

I just edited the design page of the proposal after the meeting we had 
yesterday with Vincent, Thomas and Marius: 
https://design.xwiki.org/xwiki/bin/view/Main/MacroInlineEditingContent/


To quickly sum up the main parts are:
  - we allow to specify a type in the ContentDescriptor of the macro
  - we define a new MetaDataBlock for Java macro to specify which part 
of the content is editable
  - we document a new attribute for GroupBlock/FormatBlock to specify 
which part of the content is editable in WikiMacro


Thanks again for your feedbacks!
Simon

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

On Wed, Sep 12, 2018 at 5:56 PM Simon Urli  wrote:




On 9/12/18 5:45 PM, Thomas Mortagne wrote:

Yeah I know, too many answer mails...

On Wed, Sep 12, 2018 at 5:28 PM Thomas Mortagne
 wrote:


On Wed, Sep 12, 2018 at 5:07 PM Simon Urli  wrote:




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

On Wed, Sep 12, 2018 at 5:18 PM, Simon Urli  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.


There is several things I don't like about Syntax:

* You assume that the macro content is a XWiki Rendering content
(since that's what Syntax is for) with potential parser/renderer but
that's not the case for many (if not most) macros


No, the idea is to have something extensible: a macro can add a syntax,
and on the future, specify its own custom code to be used as an editor.
Without specifying any parser/renderer then.


The org.xwiki.rendering.syntax.Syntax class "Represents a wiki syntax
that the user can use to enter wiki content" according to its
definition. If what you want is not related to a content that can be
represented as XDOM then you should introduce a new type, it will also
avoid conflicting with existing Syntax which may define something very
different that what a Macro would like to express.




* Type is more consistent with parameters and there is no reason to
have two systems for the same need: describe what kind of data and
have a reusable set of displayers for each type of data. Also it's not
just about macro parameters we use the same system in other places
(Filter input/output parameters for example).


Could you elaborate how do you see things with type? Should we create a
different type for each macro content then? And we would have to create
the proper types for plain/html/wiki content?


Here are the types you need right now:

* plain/undefined content: java.lang.String (the default since that's
the current behavior)
* wiki content for which the syntax depends on the location of the
macro: as I said in a previous mail we have existing types for this
already, Block, List or CompositeBlock (possibly XDOM for macros
which can only be used in a standalone context if we want to express
in the type even if it duplicates Macro#supportsInlineMode()) express
it well already. But since we also need "not transformed wiki content"
for inline editing in the WYSIWYG we could introduce a new type to
express that, something like "FinalCompositeBlock extends
CompositeBlock" or some other name (we could arbitrary decide that
CompositeBlock means final but I don't think it would be clear enough)

Here are a few example for the future:

* template (as defined by
https://extensions.xwiki.org/xwiki/bin/view/Extension/Template+Module#HContent):
org.xwiki.template.TemplateContent
* html: I can't think of anything clean enough so probably a new type yes
* velocity, groovy, python, etc.: new types but we can still make
generic code life a bit easier (at least on Java side) with something
like a new "VelocityContent" type annotated with
@ScriptContent("velocity") for example
* specific wiki content (I don't think we have the 

Re: [xwiki-devs] Proposal for Macro inline edition

[Thomas Mortagne]

On Wed, Sep 12, 2018 at 5:56 PM Simon Urli  wrote:
>
>
>
> On 9/12/18 5:45 PM, Thomas Mortagne wrote:
> > Yeah I know, too many answer mails...
> >
> > On Wed, Sep 12, 2018 at 5:28 PM Thomas Mortagne
> >  wrote:
> >>
> >> On Wed, Sep 12, 2018 at 5:07 PM Simon Urli  wrote:
> >>>
> >>>
> >>>
> >>> On 9/12/18 5:02 PM, Marius Dumitru Florea wrote:
>  On Wed, Sep 12, 2018 at 5:18 PM, Simon Urli  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.
> >
> > There is several things I don't like about Syntax:
> >
> > * You assume that the macro content is a XWiki Rendering content
> > (since that's what Syntax is for) with potential parser/renderer but
> > that's not the case for many (if not most) macros
>
> No, the idea is to have something extensible: a macro can add a syntax,
> and on the future, specify its own custom code to be used as an editor.
> Without specifying any parser/renderer then.

The org.xwiki.rendering.syntax.Syntax class "Represents a wiki syntax
that the user can use to enter wiki content" according to its
definition. If what you want is not related to a content that can be
represented as XDOM then you should introduce a new type, it will also
avoid conflicting with existing Syntax which may define something very
different that what a Macro would like to express.

>
> > * Type is more consistent with parameters and there is no reason to
> > have two systems for the same need: describe what kind of data and
> > have a reusable set of displayers for each type of data. Also it's not
> > just about macro parameters we use the same system in other places
> > (Filter input/output parameters for example).
>
> Could you elaborate how do you see things with type? Should we create a
> different type for each macro content then? And we would have to create
> the proper types for plain/html/wiki content?

Here are the types you need right now:

* plain/undefined content: java.lang.String (the default since that's
the current behavior)
* wiki content for which the syntax depends on the location of the
macro: as I said in a previous mail we have existing types for this
already, Block, List or CompositeBlock (possibly XDOM for macros
which can only be used in a standalone context if we want to express
in the type even if it duplicates Macro#supportsInlineMode()) express
it well already. But since we also need "not transformed wiki content"
for inline editing in the WYSIWYG we could introduce a new type to
express that, something like "FinalCompositeBlock extends
CompositeBlock" or some other name (we could arbitrary decide that
CompositeBlock means final but I don't think it would be clear enough)

Here are a few example for the future:

* template (as defined by
https://extensions.xwiki.org/xwiki/bin/view/Extension/Template+Module#HContent):
org.xwiki.template.TemplateContent
* html: I can't think of anything clean enough so probably a new type yes
* velocity, groovy, python, etc.: new types but we can still make
generic code life a bit easier (at least on Java side) with something
like a new "VelocityContent" type annotated with
@ScriptContent("velocity") for example
* specific wiki content (I don't think we have the use case right now
but never knows): same logic as for script contents I guess
* 

All that could be expressed with names instead of Java types but the
point of using Types is that:
* well that's made to define type of stuff after all :)
* more im

Re: [xwiki-devs] Proposal for Macro inline edition

[Simon Urli]

On 9/12/18 5:45 PM, Thomas Mortagne wrote:

Yeah I know, too many answer mails...

On Wed, Sep 12, 2018 at 5:28 PM Thomas Mortagne
 wrote:


On Wed, Sep 12, 2018 at 5:07 PM Simon Urli  wrote:




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

On Wed, Sep 12, 2018 at 5:18 PM, Simon Urli  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.


There is several things I don't like about Syntax:

* You assume that the macro content is a XWiki Rendering content
(since that's what Syntax is for) with potential parser/renderer but
that's not the case for many (if not most) macros


No, the idea is to have something extensible: a macro can add a syntax, 
and on the future, specify its own custom code to be used as an editor. 
Without specifying any parser/renderer then.



* Type is more consistent with parameters and there is no reason to
have two systems for the same need: describe what kind of data and
have a reusable set of displayers for each type of data. Also it's not
just about macro parameters we use the same system in other places
(Filter input/output parameters for example).


Could you elaborate how do you see things with type? Should we create a 
different type for each macro content then? And we would have to create 
the proper types for plain/html/wiki content?



* Even if macro content was only about rendering content syntax is not
very well suited to differentiate between content transformed by the
macro (takes wiki content as input data but produce something which
may have nothing to do with it) and content not transformed by the
macro (just parse/render the content with stuff around it) since it
has nothing to do with the actual content syntax.


As I said, the idea is to allow user to be able to specify their own 
editor.








Thanks,
Simon


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


On Mon, Sep 10, 2018 at 3:47 PM Simon Urli  wrote:





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


On Mon, Sep 10, 2018 at 4:07 PM, Thomas Mortagne <
thomas.morta...@xwiki.com>
wrote:

On Mon, Sep 10, 2018 at 2:56 PM Marius Dumitru Florea

 wrote:



On Mon, Sep 10, 2018 at 3:42 PM, Thomas Mortagne <


thomas.morta...@xwiki.com>


wrote:

On Mon, Sep 10, 2018 at 2:13 PM Simon Urli 



wrote:







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


Hi Simon,

On 10 Sep 2018, at 13:05, Simon Urli 



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:






  

some title
  
  Some content


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






  

some title
  
  Some content




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

Re: [xwiki-devs] Proposal for Macro inline edition

[Thomas Mortagne]

Yeah I know, too many answer mails...

On Wed, Sep 12, 2018 at 5:28 PM Thomas Mortagne
 wrote:
>
> On Wed, Sep 12, 2018 at 5:07 PM Simon Urli  wrote:
> >
> >
> >
> > On 9/12/18 5:02 PM, Marius Dumitru Florea wrote:
> > > On Wed, Sep 12, 2018 at 5:18 PM, Simon Urli  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.

There is several things I don't like about Syntax:

* You assume that the macro content is a XWiki Rendering content
(since that's what Syntax is for) with potential parser/renderer but
that's not the case for many (if not most) macros
* Type is more consistent with parameters and there is no reason to
have two systems for the same need: describe what kind of data and
have a reusable set of displayers for each type of data. Also it's not
just about macro parameters we use the same system in other places
(Filter input/output parameters for example).
* Even if macro content was only about rendering content syntax is not
very well suited to differentiate between content transformed by the
macro (takes wiki content as input data but produce something which
may have nothing to do with it) and content not transformed by the
macro (just parse/render the content with stuff around it) since it
has nothing to do with the actual content syntax.

> >
> > >
> > >>
> > >> Thanks,
> > >> Simon
> > >>
> > >>
> > >> On 9/10/18 6:46 PM, Thomas Mortagne wrote:
> > >>
> > >>> On Mon, Sep 10, 2018 at 3:47 PM Simon Urli  wrote:
> > >>>
> > 
> > 
> > 
> >  On 9/10/18 3:24 PM, Marius Dumitru Florea wrote:
> > 
> > > On Mon, Sep 10, 2018 at 4:07 PM, Thomas Mortagne <
> > > thomas.morta...@xwiki.com>
> > > wrote:
> > >
> > > On Mon, Sep 10, 2018 at 2:56 PM Marius Dumitru Florea
> > >>  wrote:
> > >>
> > >>>
> > >>> On Mon, Sep 10, 2018 at 3:42 PM, Thomas Mortagne <
> > >>>
> > >> thomas.morta...@xwiki.com>
> > >>
> > >>> wrote:
> > >>>
> > >>> On Mon, Sep 10, 2018 at 2:13 PM Simon Urli 
> > 
> > >>> wrote:
> > >>
> > >>>
> > >
> > >
> > > On 9/10/18 1:35 PM, Vincent Massol wrote:
> > >
> > >> Hi Simon,
> > >>
> > >> On 10 Sep 2018, at 13:05, Simon Urli 
> > >>>
> > >> 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:
> > 
> > >
> > >>> 
> > >>>  
> > >>>
> > >>>some title
> > >>>  
> > >>>  Some content
> > >>> 
> > >>>
> > >

Re: [xwiki-devs] Proposal for Macro inline edition

[Marius Dumitru Florea]

On Wed, Sep 12, 2018 at 6:30 PM, Thomas Mortagne 
wrote:

> On Wed, Sep 12, 2018 at 5:27 PM Marius Dumitru Florea
>  wrote:
> >
> > On Wed, Sep 12, 2018 at 6:20 PM, Thomas Mortagne <
> thomas.morta...@xwiki.com>
> > wrote:
> >
> > > On Wed, Sep 12, 2018 at 5:16 PM Marius Dumitru Florea
> > >  wrote:
> > > >
> > > > On Wed, Sep 12, 2018 at 6:02 PM, Marius Dumitru Florea <
> > > > mariusdumitru.flo...@xwiki.com> wrote:
> > > >
> > > > > On Wed, Sep 12, 2018 at 5:18 PM, Simon Urli 
> > > 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  >
> > > wrote:
> > > > >>>
> > > > 
> > > > 
> > > > 
> > > >  On 9/10/18 3:24 PM, Marius Dumitru Florea wrote:
> > > > 
> > > > > On Mon, Sep 10, 2018 at 4:07 PM, Thomas Mortagne <
> > > > > thomas.morta...@xwiki.com>
> > > > > wrote:
> > > > >
> > > > > On Mon, Sep 10, 2018 at 2:56 PM Marius Dumitru Florea
> > > > >>  wrote:
> > > > >>
> > > > >>>
> > > > >>> On Mon, Sep 10, 2018 at 3:42 PM, Thomas Mortagne <
> > > > >>>
> > > > >> thomas.morta...@xwiki.com>
> > > > >>
> > > > >>> wrote:
> > > > >>>
> > > > >>> On Mon, Sep 10, 2018 at 2:13 PM Simon Urli <
> simon.u...@xwiki.com
> > > >
> > > > 
> > > > >>> wrote:
> > > > >>
> > > > >>>
> > > > >
> > > > >
> > > > > On 9/10/18 1:35 PM, Vincent Massol wrote:
> > > > >
> > > > >> Hi Simon,
> > > > >>
> > > > >> On 10 Sep 2018, at 13:05, Simon Urli <
> simon.u...@xwiki.com>
> > > > >>>
> > > > >> wrote:
> > > > >>
> > > > >>>
> > > > >>> Hi everyone,
> > > > >>>
> > > > >>> I'm working on the roadmap issues related to the inline
> > > edition
> > > > >>>

Re: [xwiki-devs] Proposal for Macro inline edition

[Denis Gervalle]

--
Denis Gervalle
SOFTEC sa - CEO
On 12 Sep 2018, 17:20 +0200, Thomas Mortagne , wrote:
> On Wed, Sep 12, 2018 at 5:16 PM Marius Dumitru Florea
>  wrote:
> >
> > On Wed, Sep 12, 2018 at 6:02 PM, Marius Dumitru Florea <
> > mariusdumitru.flo...@xwiki.com> wrote:
> >
> > > On Wed, Sep 12, 2018 at 5:18 PM, Simon Urli  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  
> > > > > wrote:
> > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On 9/10/18 3:24 PM, Marius Dumitru Florea wrote:
> > > > > >
> > > > > > > On Mon, Sep 10, 2018 at 4:07 PM, Thomas Mortagne <
> > > > > > > thomas.morta...@xwiki.com>
> > > > > > > wrote:
> > > > > > >
> > > > > > > On Mon, Sep 10, 2018 at 2:56 PM Marius Dumitru Florea
> > > > > > > >  wrote:
> > > > > > > >
> > > > > > > > >
> > > > > > > > > On Mon, Sep 10, 2018 at 3:42 PM, Thomas Mortagne <
> > > > > > > > >
> > > > > > > > thomas.morta...@xwiki.com>
> > > > > > > >
> > > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > On Mon, Sep 10, 2018 at 2:13 PM Simon Urli 
> > > > > > > > > 
> > > > > > > > > >
> > > > > > > > > wrote:
> > > > > > > >
> > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > On 9/10/18 1:35 PM, Vincent Massol wrote:
> > > > > > > > > > >
> > > > > > > > > > > > Hi Simon,
> > > > > > > > > > > >
> > > > > > > > > > > > On 10 Sep 2018, at 13:05, 

Re: [xwiki-devs] Proposal for Macro inline edition

[Thomas Mortagne]

On Wed, Sep 12, 2018 at 5:27 PM Marius Dumitru Florea
 wrote:
>
> On Wed, Sep 12, 2018 at 6:20 PM, Thomas Mortagne 
> wrote:
>
> > On Wed, Sep 12, 2018 at 5:16 PM Marius Dumitru Florea
> >  wrote:
> > >
> > > On Wed, Sep 12, 2018 at 6:02 PM, Marius Dumitru Florea <
> > > mariusdumitru.flo...@xwiki.com> wrote:
> > >
> > > > On Wed, Sep 12, 2018 at 5:18 PM, Simon Urli 
> > 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 
> > wrote:
> > > >>>
> > > 
> > > 
> > > 
> > >  On 9/10/18 3:24 PM, Marius Dumitru Florea wrote:
> > > 
> > > > On Mon, Sep 10, 2018 at 4:07 PM, Thomas Mortagne <
> > > > thomas.morta...@xwiki.com>
> > > > wrote:
> > > >
> > > > On Mon, Sep 10, 2018 at 2:56 PM Marius Dumitru Florea
> > > >>  wrote:
> > > >>
> > > >>>
> > > >>> On Mon, Sep 10, 2018 at 3:42 PM, Thomas Mortagne <
> > > >>>
> > > >> thomas.morta...@xwiki.com>
> > > >>
> > > >>> wrote:
> > > >>>
> > > >>> On Mon, Sep 10, 2018 at 2:13 PM Simon Urli  > >
> > > 
> > > >>> wrote:
> > > >>
> > > >>>
> > > >
> > > >
> > > > On 9/10/18 1:35 PM, Vincent Massol wrote:
> > > >
> > > >> Hi Simon,
> > > >>
> > > >> On 10 Sep 2018, at 13:05, Simon Urli 
> > > >>>
> > > >> 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

Re: [xwiki-devs] Proposal for Macro inline edition

[Thomas Mortagne]

On Wed, Sep 12, 2018 at 5:07 PM Simon Urli  wrote:
>
>
>
> On 9/12/18 5:02 PM, Marius Dumitru Florea wrote:
> > On Wed, Sep 12, 2018 at 5:18 PM, Simon Urli  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  wrote:
> >>>
> 
> 
> 
>  On 9/10/18 3:24 PM, Marius Dumitru Florea wrote:
> 
> > On Mon, Sep 10, 2018 at 4:07 PM, Thomas Mortagne <
> > thomas.morta...@xwiki.com>
> > wrote:
> >
> > On Mon, Sep 10, 2018 at 2:56 PM Marius Dumitru Florea
> >>  wrote:
> >>
> >>>
> >>> On Mon, Sep 10, 2018 at 3:42 PM, Thomas Mortagne <
> >>>
> >> thomas.morta...@xwiki.com>
> >>
> >>> wrote:
> >>>
> >>> On Mon, Sep 10, 2018 at 2:13 PM Simon Urli 
> 
> >>> wrote:
> >>
> >>>
> >
> >
> > On 9/10/18 1:35 PM, Vincent Massol wrote:
> >
> >> Hi Simon,
> >>
> >> On 10 Sep 2018, at 13:05, Simon Urli 
> >>>
> >> 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:
> 
> >
> >>> 
> >>>  
> >>>
> >>>some title
> >>>  
> >>>  Some content
> >>> 
> >>>
> >>> 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.:
> 
> >
> >>> 
> >>>  
> >>>
> >>>some title
> >>>  
> >>>  Some content
> >>> 
> >>>
> >>
> >> 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
> 

Re: [xwiki-devs] Proposal for Macro inline edition

[Marius Dumitru Florea]

On Wed, Sep 12, 2018 at 6:20 PM, Thomas Mortagne 
wrote:

> On Wed, Sep 12, 2018 at 5:16 PM Marius Dumitru Florea
>  wrote:
> >
> > On Wed, Sep 12, 2018 at 6:02 PM, Marius Dumitru Florea <
> > mariusdumitru.flo...@xwiki.com> wrote:
> >
> > > On Wed, Sep 12, 2018 at 5:18 PM, Simon Urli 
> 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 
> wrote:
> > >>>
> > 
> > 
> > 
> >  On 9/10/18 3:24 PM, Marius Dumitru Florea wrote:
> > 
> > > On Mon, Sep 10, 2018 at 4:07 PM, Thomas Mortagne <
> > > thomas.morta...@xwiki.com>
> > > wrote:
> > >
> > > On Mon, Sep 10, 2018 at 2:56 PM Marius Dumitru Florea
> > >>  wrote:
> > >>
> > >>>
> > >>> On Mon, Sep 10, 2018 at 3:42 PM, Thomas Mortagne <
> > >>>
> > >> thomas.morta...@xwiki.com>
> > >>
> > >>> wrote:
> > >>>
> > >>> On Mon, Sep 10, 2018 at 2:13 PM Simon Urli  >
> > 
> > >>> wrote:
> > >>
> > >>>
> > >
> > >
> > > On 9/10/18 1:35 PM, Vincent Massol wrote:
> > >
> > >> Hi Simon,
> > >>
> > >> On 10 Sep 2018, at 13:05, Simon Urli 
> > >>>
> > >> 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:
> > 
> > >
> > >>> 
> > >>> 
> > >>>   
> > >>>   some ti

Re: [xwiki-devs] Proposal for Macro inline edition

[Thomas Mortagne]

On Wed, Sep 12, 2018 at 5:16 PM Marius Dumitru Florea
 wrote:
>
> On Wed, Sep 12, 2018 at 6:02 PM, Marius Dumitru Florea <
> mariusdumitru.flo...@xwiki.com> wrote:
>
> > On Wed, Sep 12, 2018 at 5:18 PM, Simon Urli  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  wrote:
> >>>
> 
> 
> 
>  On 9/10/18 3:24 PM, Marius Dumitru Florea wrote:
> 
> > On Mon, Sep 10, 2018 at 4:07 PM, Thomas Mortagne <
> > thomas.morta...@xwiki.com>
> > wrote:
> >
> > On Mon, Sep 10, 2018 at 2:56 PM Marius Dumitru Florea
> >>  wrote:
> >>
> >>>
> >>> On Mon, Sep 10, 2018 at 3:42 PM, Thomas Mortagne <
> >>>
> >> thomas.morta...@xwiki.com>
> >>
> >>> wrote:
> >>>
> >>> On Mon, Sep 10, 2018 at 2:13 PM Simon Urli 
> 
> >>> wrote:
> >>
> >>>
> >
> >
> > On 9/10/18 1:35 PM, Vincent Massol wrote:
> >
> >> Hi Simon,
> >>
> >> On 10 Sep 2018, at 13:05, Simon Urli 
> >>>
> >> 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:
> 
> >
> >>> 
> >>> 
> >>>   
> >>>   some title
> >>> 
> >>> Some content
> >>> 
> >>>
> >>> 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.:
> 
> >
> >>> 
> >>> 
> >>>   
> >>>   some title
> >>> 
> >>> Some content
> >>> 
> >>

Re: [xwiki-devs] Proposal for Macro inline edition

[Marius Dumitru Florea]

On Wed, Sep 12, 2018 at 6:02 PM, Marius Dumitru Florea <
mariusdumitru.flo...@xwiki.com> wrote:

> On Wed, Sep 12, 2018 at 5:18 PM, Simon Urli  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  wrote:
>>>



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

> On Mon, Sep 10, 2018 at 4:07 PM, Thomas Mortagne <
> thomas.morta...@xwiki.com>
> wrote:
>
> On Mon, Sep 10, 2018 at 2:56 PM Marius Dumitru Florea
>>  wrote:
>>
>>>
>>> On Mon, Sep 10, 2018 at 3:42 PM, Thomas Mortagne <
>>>
>> thomas.morta...@xwiki.com>
>>
>>> wrote:
>>>
>>> On Mon, Sep 10, 2018 at 2:13 PM Simon Urli 

>>> wrote:
>>
>>>
>
>
> On 9/10/18 1:35 PM, Vincent Massol wrote:
>
>> Hi Simon,
>>
>> On 10 Sep 2018, at 13:05, Simon Urli 
>>>
>> 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:

>
>>> 
>>> 
>>>   
>>>   some title
>>> 
>>> Some content
>>> 
>>>
>>> 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.:

>
>>> 
>>> 
>>>   
>>>   some title
>>> 
>>> Some content
>>> 
>>>
>>
>> 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?
>>
>>>
> Actual

Re: [xwiki-devs] 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  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  wrote:





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


On Mon, Sep 10, 2018 at 4:07 PM, Thomas Mortagne <
thomas.morta...@xwiki.com>
wrote:

On Mon, Sep 10, 2018 at 2:56 PM Marius Dumitru Florea

 wrote:



On Mon, Sep 10, 2018 at 3:42 PM, Thomas Mortagne <


thomas.morta...@xwiki.com>


wrote:

On Mon, Sep 10, 2018 at 2:13 PM Simon Urli 



wrote:







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


Hi Simon,

On 10 Sep 2018, at 13:05, Simon Urli 



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:






 
   
   some title
 
 Some content


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






 
   
   some title
 
 Some content




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 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 replacin

Re: [xwiki-devs] Proposal for Macro inline edition

[Marius Dumitru Florea]

On Wed, Sep 12, 2018 at 5:18 PM, Simon Urli  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  wrote:
>>
>>>
>>>
>>>
>>> On 9/10/18 3:24 PM, Marius Dumitru Florea wrote:
>>>
 On Mon, Sep 10, 2018 at 4:07 PM, Thomas Mortagne <
 thomas.morta...@xwiki.com>
 wrote:

 On Mon, Sep 10, 2018 at 2:56 PM Marius Dumitru Florea
>  wrote:
>
>>
>> On Mon, Sep 10, 2018 at 3:42 PM, Thomas Mortagne <
>>
> thomas.morta...@xwiki.com>
>
>> wrote:
>>
>> On Mon, Sep 10, 2018 at 2:13 PM Simon Urli 
>>>
>> wrote:
>
>>


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

> Hi Simon,
>
> On 10 Sep 2018, at 13:05, Simon Urli 
>>
> 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:
>>>

>> 
>> 
>>   
>>   some title
>> 
>> Some content
>> 
>>
>> 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.:
>>>

>> 
>> 
>>   
>>   some title
>> 
>> Some content
>> 
>>
>
> 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 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 su

Re: [xwiki-devs] 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  wrote:




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

On Mon, Sep 10, 2018 at 4:07 PM, Thomas Mortagne 
wrote:


On Mon, Sep 10, 2018 at 2:56 PM Marius Dumitru Florea
 wrote:


On Mon, Sep 10, 2018 at 3:42 PM, Thomas Mortagne <

thomas.morta...@xwiki.com>

wrote:


On Mon, Sep 10, 2018 at 2:13 PM Simon Urli 

wrote:




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

Hi Simon,


On 10 Sep 2018, at 13:05, Simon Urli 

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:




  
  some title

Some content


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




  
  some title

Some content



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 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 n

Re: [xwiki-devs] Proposal for Macro inline edition

[Thomas Mortagne]

On Mon, Sep 10, 2018 at 3:47 PM Simon Urli  wrote:
>
>
>
> On 9/10/18 3:24 PM, Marius Dumitru Florea wrote:
> > On Mon, Sep 10, 2018 at 4:07 PM, Thomas Mortagne 
> > wrote:
> >
> >> On Mon, Sep 10, 2018 at 2:56 PM Marius Dumitru Florea
> >>  wrote:
> >>>
> >>> On Mon, Sep 10, 2018 at 3:42 PM, Thomas Mortagne <
> >> thomas.morta...@xwiki.com>
> >>> wrote:
> >>>
>  On Mon, Sep 10, 2018 at 2:13 PM Simon Urli 
> >> wrote:
> >
> >
> >
> > On 9/10/18 1:35 PM, Vincent Massol wrote:
> >> Hi Simon,
> >>
> >>> On 10 Sep 2018, at 13:05, Simon Urli 
> >> 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:
> >>>
> >>> 
> >>>
> >>>  
> >>>  some title
> >>>
> >>>Some content
> >>> 
> >>>
> >>> 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.:
> >>>
> >>> 
> >>>
> >>>  
> >>>  some title
> >>>
> >>>Some content
> >>> 
> >>
> >> 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 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.). Th

Re: [xwiki-devs] 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 
wrote:


On Mon, Sep 10, 2018 at 2:56 PM Marius Dumitru Florea
 wrote:


On Mon, Sep 10, 2018 at 3:42 PM, Thomas Mortagne <

thomas.morta...@xwiki.com>

wrote:


On Mon, Sep 10, 2018 at 2:13 PM Simon Urli 

wrote:




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

Hi Simon,


On 10 Sep 2018, at 13:05, Simon Urli 

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:



   
 
 some title
   
   Some content


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



   
 
 some title
   
   Some content



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 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:


my foo

parameter

value


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:
   - 

Re: [xwiki-devs] Proposal for Macro inline edition

[Marius Dumitru Florea]

On Mon, Sep 10, 2018 at 4:07 PM, Thomas Mortagne 
wrote:

> On Mon, Sep 10, 2018 at 2:56 PM Marius Dumitru Florea
>  wrote:
> >
> > On Mon, Sep 10, 2018 at 3:42 PM, Thomas Mortagne <
> thomas.morta...@xwiki.com>
> > wrote:
> >
> > > On Mon, Sep 10, 2018 at 2:13 PM Simon Urli 
> wrote:
> > > >
> > > >
> > > >
> > > > On 9/10/18 1:35 PM, Vincent Massol wrote:
> > > > > Hi Simon,
> > > > >
> > > > >> On 10 Sep 2018, at 13:05, Simon Urli 
> 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:
> > > > >>
> > > > >> 
> > > > >>   
> > > > >> 
> > > > >> some title
> > > > >>   
> > > > >>   Some content
> > > > >> 
> > > > >>
> > > > >> 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.:
> > > > >>
> > > > >> 
> > > > >>   
> > > > >> 
> > > > >> some title
> > > > >>   
> > > > >>   Some content
> > > > >> 
> > > > >
> > > > > 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 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:
> > > > >>
> > > > >> my foo
> parameter
> > > value
> > > > >
> > > > > What’s your idea for editing parameters requiring WYSIWYG? How d

Re: [xwiki-devs] Proposal for Macro inline edition

[Thomas Mortagne]

On Mon, Sep 10, 2018 at 2:56 PM Marius Dumitru Florea
 wrote:
>
> On Mon, Sep 10, 2018 at 3:42 PM, Thomas Mortagne 
> wrote:
>
> > On Mon, Sep 10, 2018 at 2:13 PM Simon Urli  wrote:
> > >
> > >
> > >
> > > On 9/10/18 1:35 PM, Vincent Massol wrote:
> > > > Hi Simon,
> > > >
> > > >> On 10 Sep 2018, at 13:05, Simon Urli  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:
> > > >>
> > > >> 
> > > >>   
> > > >> 
> > > >> some title
> > > >>   
> > > >>   Some content
> > > >> 
> > > >>
> > > >> 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.:
> > > >>
> > > >> 
> > > >>   
> > > >> 
> > > >> some title
> > > >>   
> > > >>   Some content
> > > >> 
> > > >
> > > > 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 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:
> > > >>
> > > >> my foo parameter
> > value
> > > >
> > > > 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 su

Re: [xwiki-devs] Proposal for Macro inline edition

[Marius Dumitru Florea]

On Mon, Sep 10, 2018 at 3:42 PM, Thomas Mortagne 
wrote:

> On Mon, Sep 10, 2018 at 2:13 PM Simon Urli  wrote:
> >
> >
> >
> > On 9/10/18 1:35 PM, Vincent Massol wrote:
> > > Hi Simon,
> > >
> > >> On 10 Sep 2018, at 13:05, Simon Urli  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:
> > >>
> > >> 
> > >>   
> > >> 
> > >> some title
> > >>   
> > >>   Some content
> > >> 
> > >>
> > >> 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.:
> > >>
> > >> 
> > >>   
> > >> 
> > >> some title
> > >>   
> > >>   Some content
> > >> 
> > >
> > > 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 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:
> > >>
> > >> my foo parameter
> value
> > >
> > > 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:
> > >> Some content with  class="editable-content" data-parameter="myparameter">a
> parameter
> > >>
> > >> 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”.
>

Re: [xwiki-devs] Proposal for Macro inline edition

[Marius Dumitru Florea]

On Mon, Sep 10, 2018 at 2:35 PM, Vincent Massol  wrote:

> Hi Simon,
>
> > On 10 Sep 2018, at 13:05, Simon Urli  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:
> >
> > 
> >  
> >
> >some title
> >  
> >  Some content
> > 
> >
> > 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.:
> >
> > 
> >  
> >
> >some title
> >  
> >  Some content
> > 
>
> 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:
> >
> > my foo parameter
> value
>
> 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:
> > Some content with  class="editable-content" data-parameter="myparameter">a
> parameter
> >
> > 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]
>
>

Re: [xwiki-devs] Proposal for Macro inline edition

[Thomas Mortagne]

On Mon, Sep 10, 2018 at 2:13 PM Simon Urli  wrote:
>
>
>
> On 9/10/18 1:35 PM, Vincent Massol wrote:
> > Hi Simon,
> >
> >> On 10 Sep 2018, at 13:05, Simon Urli  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:
> >>
> >> 
> >>   
> >> 
> >> some title
> >>   
> >>   Some content
> >> 
> >>
> >> 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.:
> >>
> >> 
> >>   
> >> 
> >> some title
> >>   
> >>   Some content
> >> 
> >
> > 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 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:
> >>
> >> my foo parameter 
> >> value
> >
> > 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:
> >> Some content with  >> class="editable-content" data-parameter="myparameter">a 
> >> parameter
> >>
> >> 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 ab

Re: [xwiki-devs] 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  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:


  

some title
  
  Some content


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


  

some title
  
  Some content



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:

my foo parameter 
value


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:
Some content with a parameter

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
simon.u...@xwiki.com
More about us at http://www.xwiki.com

Re: [xwiki-devs] Proposal for Macro inline edition

[Vincent Massol]

Hi Simon,

> On 10 Sep 2018, at 13:05, Simon Urli  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:
> 
> 
>  
>
>some title
>  
>  Some content
> 
> 
> 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.:
> 
> 
>  
>
>some title
>  
>  Some content
> 

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:
> 
> my foo parameter 
> value

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:
> Some content with  class="editable-content" data-parameter="myparameter">a 
> parameter
> 
> 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]

[xwiki-devs] 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:



  

some title
  
  Some content


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



  

some title
  
  Some content


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:


my foo parameter 
value


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


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
simon.u...@xwiki.com
More about us at http://www.xwiki.com