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

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.

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