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