10 Sep
2018
10 Sep
'18
2:42 p.m.
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:
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). 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.
Hi Simon,
Here yes it's the macro developer. I'll try to be more specific in my
answers.
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?
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.
I guess that if the flag is set and the markup is not present, then the
entire content is considered as editable.
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
I'm open to suggestion on this one. "wysiwyg-editable" could be nice.
--
Thomas Mortagne
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? 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/content…) so
“editable-content” is quite close. Maybe we should have something more xwiki-specific? or
more WYSIWYG-specific? Like “editable-wysiwyg” or “wysiwyg-editable”.
My main comment is what I put above: how do we make it easy for macro developers to
specify this information.
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.
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?
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
--
Simon Urli
Software Engineer at XWiki SAS
simon.urli(a)xwiki.com
More about us at http://www.xwiki.com Thanks,
Simon
[snip]