Hi Simon and all, After thinking about this (and not being to sleep one night for some hours about it ;)), I have the following problems with the proposal so far: * It doesn’t address macro content types that are NOT in the current document’s syntax. * The API is awkward since the proposal is to return a List<Block> java Type for "macros having content written in the current document’s syntax”, while other macros containing markup would need to invent their own types.
Needs: ===== There are 2 use cases for this: A) Dynamic macro content type. Just giving 2 existing examples: Example 1: {{content syntax=“markdown/1.2”}}….{{/content}} Example 2: {{jira source=“jql | list”…}}…{{/jira}} The content types depends on some macro parameter values in each case. B) Fixed content type Example: Someone contributes a new macro in xwiki-contrib named {{markdown}} and that contains a fixed markup content in syntax “markdown/1.2”. Issues ===== The current proposal says that macro not having content written in the current document’s syntax should implement their own content Type. However there are several problems with that: * It gives an uneven API: it’s not normal to not return List<Block> type for any macro having markup that can be parsed into a List<Block>. * It means the WYSIWYG editor won’t be able to support the {{content}} or {{markdown}} macros I mentioned above which is a pity since technically it can support them when there are parsers/renderers for the syntax. Thomas mentioned (during a conf call) that we could simply add support for those special types in the WYSIWYG by hardcoding them. However that won’t work since my example with the {{markdown}} macros is about a contrib macro that doesn’t exist ATM so we cannot hardcode its support in the WYSIWYG. Proposal ======= Thus I really believe that we need to do 2 things: 1) Have the macro content’s getType() return the java type that can represent the content, i.e. List<Block> whenever the content contains markup that can be parsed into a List<Block> by one syntax parser. And have List<Block> simply means markup content. 2) Have the WYSIWYG be able to edit inline macros having markup content, i.e. that returns a List<Block> type, when they are written in a supported syntax (a supported syntax is simply a syntax for which there’s a parser and a renderer). Thus we need to have Macros be able to provide the Syntax to the WYSIWYG. There are several ways to implement 2), one simple way is to introduce a SyntaxDescriptor component role: @Role public interface SyntaxDescriptor { Syntax getSyntax(Map<String, Object> macroParameters); } And then have the WYSIWYG get a component instance of an implementation of SyntaxDescriptor with a hint being the macro id for example. And if none is found, default to a CurrentDocumentSyntaxDescriptor() that would return the current document’s syntax. Or something like this. This also means that in the WYSIWYG macro dialog box, when a parameter is modified, it would call SyntaxDescriptor#getSyntax() to get the Syntax and if that syntax doesn’t have a parser/renderer, it would display the content in the dialog box, as plain text. Planning ======= We could imagine implementing this in 2 steps if we think it’s too much for 1 step. Step 1 would mean only supporting macro content in the current doc’s syntax (as in the current proposal prior to this one in this email). Step 2 would mean breaking backward-compatibility (but getType() is @Unstable so we would have over 1 year to do it) and implementing support for all cases. WDYT? Thanks -Vincent > On 14 Sep 2018, at 16:39, Simon Urli <simon.u...@xwiki.com> wrote: > > Hi everyone, > > I just edited the design page of the proposal after the meeting we had > yesterday with Vincent, Thomas and Marius: > https://design.xwiki.org/xwiki/bin/view/Main/MacroInlineEditingContent/ > > To quickly sum up the main parts are: > - we allow to specify a type in the ContentDescriptor of the macro > - we define a new MetaDataBlock for Java macro to specify which part of the > content is editable > - we document a new attribute for GroupBlock/FormatBlock to specify which > part of the content is editable in WikiMacro > > Thanks again for your feedbacks! > Simon > > On 9/12/18 6:46 PM, Thomas Mortagne wrote: >> On Wed, Sep 12, 2018 at 5:56 PM Simon Urli <simon.u...@xwiki.com> wrote: >>> >>> >>> >>> On 9/12/18 5:45 PM, Thomas Mortagne wrote: >>>> Yeah I know, too many answer mails... >>>> >>>> On Wed, Sep 12, 2018 at 5:28 PM Thomas Mortagne >>>> <thomas.morta...@xwiki.com> wrote: >>>>> >>>>> On Wed, Sep 12, 2018 at 5:07 PM Simon Urli <simon.u...@xwiki.com> wrote: >>>>>> >>>>>> >>>>>> >>>>>> On 9/12/18 5:02 PM, Marius Dumitru Florea wrote: >>>>>>> On Wed, Sep 12, 2018 at 5:18 PM, Simon Urli <simon.u...@xwiki.com> >>>>>>> wrote: >>>>>>> >>>>>>>> Hello everyone, >>>>>>>> >>>>>>>> as a follow up of this proposal and the discussion we had, I just >>>>>>>> created >>>>>>>> the following design proposal: >>>>>>>> >>>>>>>> https://design.xwiki.org/xwiki/bin/view/Main/MacroInlineEditingContent/ >>>>>>>> >>>>>>>> Let me know what you think about it. >>>>>>>> >>>>>>> >>>>>>> Regarding the Content Descriptor, which Syntax(es) will activate the >>>>>>> inline >>>>>>> editing of the macro content? I'm asking because the Syntax of the >>>>>>> content >>>>>>> is not the most important part. The most important part for the WYSIWYG >>>>>>> editor is to know if the macro code outputs the macro content without >>>>>>> transforming it. Without this it cannot enable inline editing. If the >>>>>>> macro >>>>>>> output is rendered without modifications then the WYSIWYG editor can >>>>>>> enable >>>>>>> inline editing but it needs to know in which Syntax to convert the HTML >>>>>>> produced while editing inline. So to summarize: >>>>>>> >>>>>>> * First the WYSIWYG editor needs to know if the macro content is >>>>>>> rendered >>>>>>> without modifications >>>>>>> * then the WYSIWYG editor needs to know the target Syntax to which to >>>>>>> convert the HTML >>>>>>> >>>>>> >>>>>> The WYSIWYG editor will know if it's editable if it exists a parser and >>>>>> a renderer for this syntax. >>>>> >>>>> You are mixing different things here: >>>>> * a macro which can be edited with A WYSIWYG for example in the model >>>>> macro form >>>>> * a macro content which IS NOT TRANSFORMED BY THE MACRO and so can be >>>>> edited inline >>>>> >>> >>> >>>>>> So the target syntax is the given macro syntax. >>>> >>>> There is several things I don't like about Syntax: >>>> >>>> * You assume that the macro content is a XWiki Rendering content >>>> (since that's what Syntax is for) with potential parser/renderer but >>>> that's not the case for many (if not most) macros >>> >>> No, the idea is to have something extensible: a macro can add a syntax, >>> and on the future, specify its own custom code to be used as an editor. >>> Without specifying any parser/renderer then. >> 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. >>> >>>> * Type is more consistent with parameters and there is no reason to >>>> have two systems for the same need: describe what kind of data and >>>> have a reusable set of displayers for each type of data. Also it's not >>>> just about macro parameters we use the same system in other places >>>> (Filter input/output parameters for example). >>> >>> Could you elaborate how do you see things with type? Should we create a >>> different type for each macro content then? And we would have to create >>> the proper types for plain/html/wiki content? >> 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#HContent): >> 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 <simon.u...@xwiki.com> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 9/10/18 3:24 PM, Marius Dumitru Florea wrote: >>>>>>>>>> >>>>>>>>>>> On Mon, Sep 10, 2018 at 4:07 PM, Thomas Mortagne < >>>>>>>>>>> thomas.morta...@xwiki.com> >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> On Mon, Sep 10, 2018 at 2:56 PM Marius Dumitru Florea >>>>>>>>>>>> <mariusdumitru.flo...@xwiki.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Mon, Sep 10, 2018 at 3:42 PM, Thomas Mortagne < >>>>>>>>>>>>> >>>>>>>>>>>> thomas.morta...@xwiki.com> >>>>>>>>>>>> >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> On Mon, Sep 10, 2018 at 2:13 PM Simon Urli <simon.u...@xwiki.com> >>>>>>>>>>>>>> >>>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 9/10/18 1:35 PM, Vincent Massol wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Hi Simon, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 10 Sep 2018, at 13:05, Simon Urli <simon.u...@xwiki.com> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 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.u...@xwiki.com >>>>>>>>>>>>>>> More about us at http://www.xwiki.com >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> Thomas Mortagne >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> Thomas Mortagne >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Simon Urli >>>>>>>>>> Software Engineer at XWiki SAS >>>>>>>>>> simon.u...@xwiki.com >>>>>>>>>> More about us at http://www.xwiki.com >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> -- >>>>>>>> Simon Urli >>>>>>>> Software Engineer at XWiki SAS >>>>>>>> simon.u...@xwiki.com >>>>>>>> More about us at http://www.xwiki.com >>>>>>>> >>>>>> >>>>>> -- >>>>>> Simon Urli >>>>>> Software Engineer at XWiki SAS >>>>>> simon.u...@xwiki.com >>>>>> More about us at http://www.xwiki.com >>>>> >>>>> >>>>> >>>>> -- >>>>> Thomas Mortagne >>>> >>>> >>>> >>> >>> -- >>> Simon Urli >>> Software Engineer at XWiki SAS >>> simon.u...@xwiki.com >>> More about us at http://www.xwiki.com > > -- > Simon Urli > Software Engineer at XWiki SAS > simon.u...@xwiki.com > More about us at http://www.xwiki.com