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

On Wed, Sep 12, 2018 at 6:02 PM, Marius Dumitru Florea < mariusdumitru.florea(a)xwiki.com&gt; wrote: > On Wed, Sep 12, 2018 at 5:18 PM, Simon Urli &lt;simon.urli(a)xwiki.com&gt;

>> Hello everyone, >> >> as a follow up of this proposal and the discussion we had, I just

>> the following design proposal: >> >> https://design.xwiki.org/xwiki/bin/view/Main/

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

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

> the macro output is rendered without modifications then the WYSIWYG

> can enable inline editing but it needs to know in which Syntax to

> the HTML produced while editing inline. So to summarize: > * First the WYSIWYG editor needs to know if the macro content is

Let me try to make this even more clear. The WYSIWYG editor needs to

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

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

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 &lt;simon.urli(a)xwiki.com&gt;

>>>>>>>> >>>>>>> wrote: >>>>>> >>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 9/10/18 1:35 PM, Vincent Massol wrote: >>>>>>>>> >>>>>>>>>> Hi Simon, >>>>>>>>>> >>>>>>>>>> On 10 Sep 2018, at 13:05, Simon Urli &lt;simon.urli(a)xwiki.com&gt; >>>>>>>>>>> >>>>>>>>>> wrote: >>>>>> >>>>>>> >>>>>>>>>>> Hi everyone, >>>>>>>>>>> >>>>>>>>>>> I'm working on the roadmap issues related to the inline

>>>>>>>>>>> >>>>>>>>>> with >>>>>> >>>>>>> WYSIWYG editor for macro content and macro parameters. >>>>>>>> >>>>>>>>> >>>>>>>>>> Cool :) We've been waiting for a long time about this

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

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

>>>>>>>> >>>>>>> editor? >>>>>> >>>>>>> >>>>>>>>> Actually we're planning to add the getter/setter **and** the >>>>>>>>> specific >>>>>>>>> markup for the editor. The getter/setter (which I called the

>>>>>>>>> above), is here to specify that the macro will contain inline >>>>>>>>> >>>>>>>> editable >>>>>> >>>>>>> content in WYSIWYG. The markup will specify *where* exactly is

>>>>>>>>> content, and what shouldn't be changed. >>>>>>>>> >>>>>>>> >>>>>>>> About that "flag", you seems to plan a boolean but I feel

>>>>>>>> more generic that we want to introduce since a long time would

>>>>>>>> better: make the content descriptor return a type like

>>>>>>>> descriptors do. The kind of inline editing you have in mind

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

>>>>>> content types for other use cases so it's a good occasion. Also

>>>>>> you use the type you can differentiate between wiki content and

>>>>>> content and support inline editing of HTML macro in the same

>>>>>> for example. >>>>>> >>>>>> >>>>> I'm not against your proposal. It's a bit more work though, to

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

>>>> content descriptor is defined as an html content, then the html

>>>> would be used, if it's defined as an inline content, then it would

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

>>>> the different types for edition (e.g. a boolean parameter only

>>>> text input). So wouldn't it be a priority before putting a type on

>>>> content descriptor itself? >>>> >>> >>> The WYSIWYG does miss a lot of displayers and we need work on that

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

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

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

>>>>>>>> >>>>>>> parts of >>>>>> >>>>>>> the content not editable (for example)? >>>>>>>> >>>>>>>>> >>>>>>>>> It's exactly why yes. On my example, the macro user won't be

>>>>>>>>> to >>>>>>>>> change the content of the title. >>>>>>>>> >>>>>>>>> >>>>>>>>>> Technically Macros don’t generate HTML, only XDOM. So in

>>>>>>>>>> >>>>>>>>> make >>>>>> >>>>>>> it easier for java macro developers, I’d suggest to introduce

>>>>>>>> new >>>>>>>> wrapping Block to indicate this information. We might need

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

>>>>>>>>> it >>>>>>>>> seems to make sense indeed. >>>>>>>>> >>>>>>>>> >>>>>>>>>> About parameters, our idea was to define a new metadata

>>>>>>>>>>> >>>>>>>>>> and >>>>>> >>>>>>> to ask users to use it for specifying the content is editable,

>>>>>>>> as >>>>>>>> >>>>>>> for >>>>>> >>>>>>> a parameter named foo: >>>>>>>> >>>>>>>>> >>>>>>>>>>> <span class="editable-content" data-parameter="foo">my foo >>>>>>>>>>> >>>>>>>>>> parameter >>>>>> >>>>>>> value</span> >>>>>>>> >>>>>>>>> >>>>>>>>>> What’s your idea for editing parameters requiring WYSIWYG?

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

>>>>>>>>> with >>>>>>>>> the CKEditor for the editable content/parameters >>>>>>>>> - when editing the macro, you stay in the main editor UI,

>>>>>>>>> the >>>>>>>>> content is now editable instead of opening back the macro UI >>>>>>>>> >>>>>>>>> >>>>>>>>>> However I don't know right now how the editor would manage

>>>>>>>>>>> >>>>>>>>>> such >>>>>> >>>>>>> as: >>>>>>>> >>>>>>>>> <span class="editable-content">Some content with <span >>>>>>>>>>> >>>>>>>>>> class="editable-content" data-parameter="myparameter">a >>>>>>>> parameter</span></span> >>>>>>>> >>>>>>>>> >>>>>>>>>>> So: >>>>>>>>>>> 1. Do you agree on the usage of a class named >>>>>>>>>>> "editable-content" >>>>>>>>>>> >>>>>>>>>> which would be used as a tag to allow inline edition? >>>>>>>> >>>>>>>>> >>>>>>>>>> Small details, there’s already the “contenteditable” notion

>>>>>>>>>> >>>>>>>>> exists (see https://developer.mozilla.org/ >>>>>>>> fr/docs/Web/HTML/Attributs_ >>>>>>>> universels/contenteditable) so “editable-content” is quite

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

>>>>>>>>>> >>>>>>>>> macro >>>>>> >>>>>>> developers to specify this information. >>>>>>>> >>>>>>>>> >>>>>>>>>> 2. WDYT about using a data-parameter and this class for

>>>>>>>>>>> >>>>>>>>>> editing of parameters? >>>>>>>> >>>>>>>>> >>>>>>>>>> Before answering that part, I would need to understand what’s

>>>>>>>>>> >>>>>>>>> proposal in term of UI. >>>>>>>> >>>>>>>>> >>>>>>>>>> Note that the main use case is for content but it’s nice if

>>>>>>>>>> can >>>>>>>>>> >>>>>>>>> also support parameters. Now, accepting markup in parameters

>>>>>>>> >>>>>>> really >>>>>> >>>>>>> a great use case IMO and is usually a design issue so I’m not

>>>>>>>> should spend that much time in supporting that. WDYT? >>>>>>>> >>>>>>>>> >>>>>>>>> We just discuss about macro parameters with Ludovic and

>>>>>>>>> >>>>>>>> they >>>>>> >>>>>>> cannot support line returns, so we might have to use a custom

>>>>>>>>> >>>>>>>> for >>>>>> >>>>>>> those. >>>>>>>>> >>>>>>>>> >>>>>>>>>> The only macro parameter I know ATM that supports markup is

>>>>>>>>>> >>>>>>>>> “title” param of the {{box}} macro and I think it’s badly

>>>>>>>> >>>>>>> Note: >>>>>> >>>>>>> if you check the recent {{figure}} macro, I implemented this

>>>>>>>> >>>>>>> having >>>>>> >>>>>>> a {{figureCaption}} nested macro. >>>>>>>> >>>>>>>>> >>>>>>>>>> BTW this raises a question, will you support WYSIWYG editing

>>>>>>>>>> >>>>>>>>> nested >>>>>> >>>>>>> macros? >>>>>>>> >>>>>>>>> >>>>>>>>> Not for the moment. >>>>>>>>> >>>>>>>>> Simon >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> -Vincent >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>>> Simon >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> [snip] >>>>>>>>>> >>>>>>>>>> >>>>>>>>> -- >>>>>>>>> Simon Urli >>>>>>>>> Software Engineer at XWiki SAS >>>>>>>>> simon.urli(a)xwiki.com >>>>>>>>> More about us at http://www.xwiki.com >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Thomas Mortagne >>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Thomas Mortagne >>>>>> >>>>>> >>>> -- >>>> Simon Urli >>>> Software Engineer at XWiki SAS >>>> simon.urli(a)xwiki.com >>>> More about us at http://www.xwiki.com >>>> >>> >>> >>> >>> >> -- >> Simon Urli >> Software Engineer at XWiki SAS >> simon.urli(a)xwiki.com >> More about us at http://www.xwiki.com >> > >