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 >> -- Simon Urli Software Engineer at XWiki SAS simon.urli(a)xwiki.com More about us at http://www.xwiki.com