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

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