On Wed, Sep 12, 2018 at 6:20 PM, Thomas Mortagne <[email protected]> wrote:
> On Wed, Sep 12, 2018 at 5:16 PM Marius Dumitru Florea > <[email protected]> wrote: > > > > On Wed, Sep 12, 2018 at 6:02 PM, Marius Dumitru Florea < > > [email protected]> wrote: > > > > > On Wed, Sep 12, 2018 at 5:18 PM, Simon Urli <[email protected]> > 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 > > > > > > > Let me try to make this even more clear. The WYSIWYG editor needs to > take > > the following decisions: > > > > [OPTIONAL] "Should I display the macro content (plain) text area on the > > Macro Edit dialog?" > > > > If the macro content can be edited inline within the editing area then it > > probably make sense to not display the text area on the Macro Edit > dialog. > > But for this we need some *static* information in the macro descriptor to > > indicate that the macro content can be edited inline. > > > > [MANDATORY] "Should I enable inline editing for this macro?" > > > > The WYSIWYG editor can scan the macro output DOM (HTML) for some special > > markers (attributes) to determine if the macro content can be edited > inline > > > > > > [MANDATORY] "To which syntax do I need to convert the HTML from the macro > > content?" > > > > When saving the page the editor needs to convert the macro content from > > HTML to some syntax. The target syntax needs to be specified either in > the > > macro output DOM (HTML) using some attributes or in the macro descriptor. > > > That's only if the syntax is different from the current syntax (which > is not the case for most inline edited macros containing wiki > content). > Exactly! The macros we target with this feature use the current syntax (of the page where the macro is called) for their content. > > > > > Hope this helps, > > Marius > > > > > > > > > > > > >> > > >> Thanks, > > >> Simon > > >> > > >> > > >> On 9/10/18 6:46 PM, Thomas Mortagne wrote: > > >> > > >>> On Mon, Sep 10, 2018 at 3:47 PM Simon Urli <[email protected]> > wrote: > > >>> > > >>>> > > >>>> > > >>>> > > >>>> On 9/10/18 3:24 PM, Marius Dumitru Florea wrote: > > >>>> > > >>>>> On Mon, Sep 10, 2018 at 4:07 PM, Thomas Mortagne < > > >>>>> [email protected]> > > >>>>> wrote: > > >>>>> > > >>>>> On Mon, Sep 10, 2018 at 2:56 PM Marius Dumitru Florea > > >>>>>> <[email protected]> wrote: > > >>>>>> > > >>>>>>> > > >>>>>>> On Mon, Sep 10, 2018 at 3:42 PM, Thomas Mortagne < > > >>>>>>> > > >>>>>> [email protected]> > > >>>>>> > > >>>>>>> wrote: > > >>>>>>> > > >>>>>>> On Mon, Sep 10, 2018 at 2:13 PM Simon Urli <[email protected] > > > > >>>>>>>> > > >>>>>>> wrote: > > >>>>>> > > >>>>>>> > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> On 9/10/18 1:35 PM, Vincent Massol wrote: > > >>>>>>>>> > > >>>>>>>>>> Hi Simon, > > >>>>>>>>>> > > >>>>>>>>>> On 10 Sep 2018, at 13:05, Simon Urli <[email protected]> > > >>>>>>>>>>> > > >>>>>>>>>> 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 > > >>>>>>>>> [email protected] > > >>>>>>>>> More about us at http://www.xwiki.com > > >>>>>>>>> > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> -- > > >>>>>>>> Thomas Mortagne > > >>>>>>>> > > >>>>>>>> > > >>>>>> > > >>>>>> > > >>>>>> -- > > >>>>>> Thomas Mortagne > > >>>>>> > > >>>>>> > > >>>> -- > > >>>> Simon Urli > > >>>> Software Engineer at XWiki SAS > > >>>> [email protected] > > >>>> More about us at http://www.xwiki.com > > >>>> > > >>> > > >>> > > >>> > > >>> > > >> -- > > >> Simon Urli > > >> Software Engineer at XWiki SAS > > >> [email protected] > > >> More about us at http://www.xwiki.com > > >> > > > > > > > > > > -- > Thomas Mortagne >
