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