On 9/10/18 1:35 PM, Vincent Massol wrote:
Hi Simon,

On 10 Sep 2018, at 13:05, Simon Urli <[email protected]> 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.

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
[email protected]
More about us at http://www.xwiki.com

Reply via email to