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