On Wed, Sep 12, 2018 at 6:30 PM, Thomas Mortagne <[email protected]> wrote:
> On Wed, Sep 12, 2018 at 5:27 PM Marius Dumitru Florea > <[email protected]> wrote: > > > > 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. > > > My point is that the WYSIWYG know the syntax already you don't need > each macro to provide it as metadata. > I fully agree with you. > > > > > > > > > > > > > > > > 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 > > > > > > > -- > Thomas Mortagne >
