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

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