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