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