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

On Wed, Sep 12, 2018 at 5:56 PM Simon Urli &lt;simon.urli(a)xwiki.com&gt; wrote: The org.xwiki.rendering.syntax.Syntax class "Represents a wiki syntax that the user can use to enter wiki content" according to its definition. If what you want is not related to a content that can be represented as XDOM then you should introduce a new type, it will also avoid conflicting with existing Syntax which may define something very different that what a Macro would like to express. Here are the types you need right now: * plain/undefined content: java.lang.String (the default since that's the current behavior) * wiki content for which the syntax depends on the location of the macro: as I said in a previous mail we have existing types for this already, Block, List<XDOM> or CompositeBlock (possibly XDOM for macros which can only be used in a standalone context if we want to express in the type even if it duplicates Macro#supportsInlineMode()) express it well already. But since we also need "not transformed wiki content" for inline editing in the WYSIWYG we could introduce a new type to express that, something like "FinalCompositeBlock extends CompositeBlock" or some other name (we could arbitrary decide that CompositeBlock means final but I don't think it would be clear enough) Here are a few example for the future: * template (as defined by https://extensions.xwiki.org/xwiki/bin/view/Extension/Template+Module#HCont…): org.xwiki.template.TemplateContent * html: I can't think of anything clean enough so probably a new type yes * velocity, groovy, python, etc.: new types but we can still make generic code life a bit easier (at least on Java side) with something like a new "VelocityContent" type annotated with @ScriptContent("velocity") for example * specific wiki content (I don't think we have the use case right now but never knows): same logic as for script contents I guess * <many other types used in the parameters already> All that could be expressed with names instead of Java types but the point of using Types is that: * well that's made to define type of stuff after all :) * more importantly we can use the same system for macro parameters, filter properties and content (and other stuff in the future) to find out a suitable displayer/editor. For example some macro have the need to take wiki content as parameter too. > >> * Even if macro content was only about rendering content syntax is not >> very well suited to differentiate between content transformed by the >> macro (takes wiki content as input data but produce something which >> may have nothing to do with it) and content not transformed by the >> macro (just parse/render the content with stuff around it) since it >> has nothing to do with the actual content syntax. > > As I said, the idea is to allow user to be able to specify their own > editor. >> >>>> >>>>> >>>>>> >>>>>> 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 >> >> >> > > -- > Simon Urli > Software Engineer at XWiki SAS > simon.urli(a)xwiki.com > More about us at http://www.xwiki.com