On Wed, Sep 12, 2018 at 5:27 PM Marius Dumitru Florea
<mariusdumitru.flo...@xwiki.com> wrote:
>
> On Wed, Sep 12, 2018 at 6:20 PM, Thomas Mortagne <thomas.morta...@xwiki.com>
> wrote:
>
> > On Wed, Sep 12, 2018 at 5:16 PM Marius Dumitru Florea
> > <mariusdumitru.flo...@xwiki.com> wrote:
> > >
> > > On Wed, Sep 12, 2018 at 6:02 PM, Marius Dumitru Florea <
> > > mariusdumitru.flo...@xwiki.com> wrote:
> > >
> > > > On Wed, Sep 12, 2018 at 5:18 PM, Simon Urli <simon.u...@xwiki.com>
> > 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.
>
>
> >
> > >
> > > 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 <simon.u...@xwiki.com>
> > wrote:
> > > >>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>> On 9/10/18 3:24 PM, Marius Dumitru Florea wrote:
> > > >>>>
> > > >>>>> 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.
> > > >>>>>
> > > >>>>
> > > >>> 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
> > > >>>>>>>>> simon.u...@xwiki.com
> > > >>>>>>>>> More about us at http://www.xwiki.com
> > > >>>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>> --
> > > >>>>>>>> Thomas Mortagne
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>>>> --
> > > >>>>>> Thomas Mortagne
> > > >>>>>>
> > > >>>>>>
> > > >>>> --
> > > >>>> Simon Urli
> > > >>>> Software Engineer at XWiki SAS
> > > >>>> simon.u...@xwiki.com
> > > >>>> More about us at http://www.xwiki.com
> > > >>>>
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >> --
> > > >> Simon Urli
> > > >> Software Engineer at XWiki SAS
> > > >> simon.u...@xwiki.com
> > > >> More about us at http://www.xwiki.com
> > > >>
> > > >
> > > >
> >
> >
> >
> > --
> > Thomas Mortagne
> >
--
Thomas Mortagne
