12 Sep
2018
12 Sep
'18
5:32 p.m.
--
Denis Gervalle
SOFTEC sa - CEO
On 12 Sep 2018, 17:20 +0200, Thomas Mortagne <thomas.mortagne(a)xwiki.com>om>, wrote:
On Wed, Sep 12, 2018 at 5:16 PM Marius Dumitru Florea
<mariusdumitru.florea(a)xwiki.com> wrote:
Well according to the idea that macro content, or even macro parameter could be used to
render the content of the macro, this is even more complex since there could be for a
single macro, multiple editable area, that could go either to a parameter or the content
of the macro, and each of these areas could have a different syntax supported.
I would also add that it should also be useful to communicate to the editor the type of
formatting allowed in these contents. Sometime, you wish only simple inline formatting
like bold, italic… but you might also support block formatting like paragraph and list.
So, the editable areas should be aware of this to properly update the editor tool bar and
prevent unsupported html to have to be converted. If you take a simple titled box macro,
you have a title that goes to a parameter, could be plain text or better xwiki syntax, but
only allow inline formatting like bold/italic/superscripts… since it is rendered in a h
tag, and a macro content in full wiki syntax that could hold paragraphs, list and
everything.
On Wed, Sep 12, 2018 at 6:02 PM, Marius Dumitru Florea <
mariusdumitru.florea(a)xwiki.com> wrote:
On Wed, Sep 12, 2018 at 5:18 PM, Simon Urli
<simon.urli(a)xwiki.com> wrote:
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
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
[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).
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.urli(a)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.mortagne(a)xwiki.com>
> > > > > wrote:
> > > > >
> > > > > On Mon, Sep 10, 2018 at 2:56 PM Marius Dumitru Florea
> > > > > > <mariusdumitru.florea(a)xwiki.com> wrote:
> > > > > >
> > > > > > >
> > > > > > > On Mon, Sep 10, 2018 at 3:42 PM, Thomas Mortagne <
> > > > > > >
> > > > > > thomas.mortagne(a)xwiki.com>
> > > > > >
> > > > > > > wrote:
> > > > > > >
> > > > > > > On Mon, Sep 10, 2018 at 2:13 PM Simon Urli
<simon.urli(a)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.urli(a)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.urli(a)xwiki.com
> > > > > > > > > More about us at http://www.xwiki.com
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Thomas Mortagne
> > > > > > > >
> > > > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Thomas Mortagne
> > > > > >
> > > > > >
> > > > --
> > > > Simon Urli
> > > > Software Engineer at XWiki SAS
> > > > simon.urli(a)xwiki.com
> > > > More about us at http://www.xwiki.com
> > > >
> > >
> > >
> > >
> > >
> > --
> > Simon Urli
> > Software Engineer at XWiki SAS
> > simon.urli(a)xwiki.com
> > More about us at http://www.xwiki.com
> >
>
>
--
Thomas Mortagne