Hi Simon and all,
After thinking about this (and not being to sleep one night for some hours
about it ;)), I have the following problems with the proposal so far:
* It doesn’t address macro content types that are NOT in the current document’s
syntax.
* The API is awkward since the proposal is to return a List<Block> java Type
for "macros having content written in the current document’s syntax”, while
other macros containing markup would need to invent their own types.
Needs:
=====
There are 2 use cases for this:
A) Dynamic macro content type.
Just giving 2 existing examples:
Example 1: {{content syntax=“markdown/1.2”}}….{{/content}}
Example 2: {{jira source=“jql | list”…}}…{{/jira}}
The content types depends on some macro parameter values in each case.
B) Fixed content type
Example: Someone contributes a new macro in xwiki-contrib named {{markdown}}
and that contains a fixed markup content in syntax “markdown/1.2”.
Issues
=====
The current proposal says that macro not having content written in the current
document’s syntax should implement their own content Type.
However there are several problems with that:
* It gives an uneven API: it’s not normal to not return List<Block> type for
any macro having markup that can be parsed into a List<Block>.
* It means the WYSIWYG editor won’t be able to support the {{content}} or
{{markdown}} macros I mentioned above which is a pity since technically it can
support them when there are parsers/renderers for the syntax. Thomas mentioned
(during a conf call) that we could simply add support for those special types
in the WYSIWYG by hardcoding them. However that won’t work since my example
with the {{markdown}} macros is about a contrib macro that doesn’t exist ATM so
we cannot hardcode its support in the WYSIWYG.
Proposal
=======
Thus I really believe that we need to do 2 things:
1) Have the macro content’s getType() return the java type that can represent
the content, i.e. List<Block> whenever the content contains markup that can be
parsed into a List<Block> by one syntax parser. And have List<Block> simply
means markup content.
2) Have the WYSIWYG be able to edit inline macros having markup content, i.e.
that returns a List<Block> type, when they are written in a supported syntax (a
supported syntax is simply a syntax for which there’s a parser and a renderer).
Thus we need to have Macros be able to provide the Syntax to the WYSIWYG.
There are several ways to implement 2), one simple way is to introduce a
SyntaxDescriptor component role:
@Role
public interface SyntaxDescriptor
{
Syntax getSyntax(Map<String, Object> macroParameters);
}
And then have the WYSIWYG get a component instance of an implementation of
SyntaxDescriptor with a hint being the macro id for example. And if none is
found, default to a CurrentDocumentSyntaxDescriptor() that would return the
current document’s syntax. Or something like this.
This also means that in the WYSIWYG macro dialog box, when a parameter is
modified, it would call SyntaxDescriptor#getSyntax() to get the Syntax and if
that syntax doesn’t have a parser/renderer, it would display the content in the
dialog box, as plain text.
Planning
=======
We could imagine implementing this in 2 steps if we think it’s too much for 1
step. Step 1 would mean only supporting macro content in the current doc’s
syntax (as in the current proposal prior to this one in this email). Step 2
would mean breaking backward-compatibility (but getType() is @Unstable so we
would have over 1 year to do it) and implementing support for all cases.
WDYT?
Thanks
-Vincent
> On 14 Sep 2018, at 16:39, Simon Urli <[email protected]> wrote:
>
> Hi everyone,
>
> I just edited the design page of the proposal after the meeting we had
> yesterday with Vincent, Thomas and Marius:
> https://design.xwiki.org/xwiki/bin/view/Main/MacroInlineEditingContent/
>
> To quickly sum up the main parts are:
> - we allow to specify a type in the ContentDescriptor of the macro
> - we define a new MetaDataBlock for Java macro to specify which part of the
> content is editable
> - we document a new attribute for GroupBlock/FormatBlock to specify which
> part of the content is editable in WikiMacro
>
> Thanks again for your feedbacks!
> Simon
>
> On 9/12/18 6:46 PM, Thomas Mortagne wrote:
>> On Wed, Sep 12, 2018 at 5:56 PM Simon Urli <[email protected]> wrote:
>>>
>>>
>>>
>>> On 9/12/18 5:45 PM, Thomas Mortagne wrote:
>>>> Yeah I know, too many answer mails...
>>>>
>>>> On Wed, Sep 12, 2018 at 5:28 PM Thomas Mortagne
>>>> <[email protected]> wrote:
>>>>>
>>>>> On Wed, Sep 12, 2018 at 5:07 PM Simon Urli <[email protected]> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 9/12/18 5:02 PM, Marius Dumitru Florea wrote:
>>>>>>> On Wed, Sep 12, 2018 at 5:18 PM, Simon Urli <[email protected]>
>>>>>>> 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
>>>>>>>
>>>>>>
>>>>>> The WYSIWYG editor will know if it's editable if it exists a parser and
>>>>>> a renderer for this syntax.
>>>>>
>>>>> You are mixing different things here:
>>>>> * a macro which can be edited with A WYSIWYG for example in the model
>>>>> macro form
>>>>> * a macro content which IS NOT TRANSFORMED BY THE MACRO and so can be
>>>>> edited inline
>>>>>
>>>
>>>
>>>>>> So the target syntax is the given macro syntax.
>>>>
>>>> There is several things I don't like about Syntax:
>>>>
>>>> * You assume that the macro content is a XWiki Rendering content
>>>> (since that's what Syntax is for) with potential parser/renderer but
>>>> that's not the case for many (if not most) macros
>>>
>>> No, the idea is to have something extensible: a macro can add a syntax,
>>> and on the future, specify its own custom code to be used as an editor.
>>> Without specifying any parser/renderer then.
>> The org.xwiki.rendering.syntax.Syntax class "Represents a wiki syntax
>> that the user can use to enter wiki content" according to its
>> definition. If what you want is not related to a content that can be
>> represented as XDOM then you should introduce a new type, it will also
>> avoid conflicting with existing Syntax which may define something very
>> different that what a Macro would like to express.
>>>
>>>> * Type is more consistent with parameters and there is no reason to
>>>> have two systems for the same need: describe what kind of data and
>>>> have a reusable set of displayers for each type of data. Also it's not
>>>> just about macro parameters we use the same system in other places
>>>> (Filter input/output parameters for example).
>>>
>>> Could you elaborate how do you see things with type? Should we create a
>>> different type for each macro content then? And we would have to create
>>> the proper types for plain/html/wiki content?
>> Here are the types you need right now:
>> * plain/undefined content: java.lang.String (the default since that's
>> the current behavior)
>> * wiki content for which the syntax depends on the location of the
>> macro: as I said in a previous mail we have existing types for this
>> already, Block, List<XDOM> or CompositeBlock (possibly XDOM for macros
>> which can only be used in a standalone context if we want to express
>> in the type even if it duplicates Macro#supportsInlineMode()) express
>> it well already. But since we also need "not transformed wiki content"
>> for inline editing in the WYSIWYG we could introduce a new type to
>> express that, something like "FinalCompositeBlock extends
>> CompositeBlock" or some other name (we could arbitrary decide that
>> CompositeBlock means final but I don't think it would be clear enough)
>> Here are a few example for the future:
>> * template (as defined by
>> https://extensions.xwiki.org/xwiki/bin/view/Extension/Template+Module#HContent):
>> org.xwiki.template.TemplateContent
>> * html: I can't think of anything clean enough so probably a new type yes
>> * velocity, groovy, python, etc.: new types but we can still make
>> generic code life a bit easier (at least on Java side) with something
>> like a new "VelocityContent" type annotated with
>> @ScriptContent("velocity") for example
>> * specific wiki content (I don't think we have the use case right now
>> but never knows): same logic as for script contents I guess
>> * <many other types used in the parameters already>
>> All that could be expressed with names instead of Java types but the
>> point of using Types is that:
>> * well that's made to define type of stuff after all :)
>> * more importantly we can use the same system for macro parameters,
>> filter properties and content (and other stuff in the future) to find
>> out a suitable displayer/editor. For example some macro have the need
>> to take wiki content as parameter too.
>>>
>>>> * Even if macro content was only about rendering content syntax is not
>>>> very well suited to differentiate between content transformed by the
>>>> macro (takes wiki content as input data but produce something which
>>>> may have nothing to do with it) and content not transformed by the
>>>> macro (just parse/render the content with stuff around it) since it
>>>> has nothing to do with the actual content syntax.
>>>
>>> As I said, the idea is to allow user to be able to specify their own
>>> editor.
>>>>
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Simon
>>>>>>>>
>>>>>>>>
>>>>>>>> On 9/10/18 6:46 PM, Thomas Mortagne wrote:
>>>>>>>>
>>>>>>>>> On Mon, Sep 10, 2018 at 3:47 PM Simon Urli <[email protected]>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 9/10/18 3:24 PM, Marius Dumitru Florea wrote:
>>>>>>>>>>
>>>>>>>>>>> On Mon, Sep 10, 2018 at 4:07 PM, Thomas Mortagne <
>>>>>>>>>>> [email protected]>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> On Mon, Sep 10, 2018 at 2:56 PM Marius Dumitru Florea
>>>>>>>>>>>> <[email protected]> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Mon, Sep 10, 2018 at 3:42 PM, Thomas Mortagne <
>>>>>>>>>>>>>
>>>>>>>>>>>> [email protected]>
>>>>>>>>>>>>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Mon, Sep 10, 2018 at 2:13 PM Simon Urli <[email protected]>
>>>>>>>>>>>>>>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>> [email protected]
>>>>>>>>>>>>>>> More about us at http://www.xwiki.com
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> Thomas Mortagne
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Thomas Mortagne
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Simon Urli
>>>>>>>>>> Software Engineer at XWiki SAS
>>>>>>>>>> [email protected]
>>>>>>>>>> More about us at http://www.xwiki.com
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>> --
>>>>>>>> Simon Urli
>>>>>>>> Software Engineer at XWiki SAS
>>>>>>>> [email protected]
>>>>>>>> More about us at http://www.xwiki.com
>>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Simon Urli
>>>>>> Software Engineer at XWiki SAS
>>>>>> [email protected]
>>>>>> More about us at http://www.xwiki.com
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Thomas Mortagne
>>>>
>>>>
>>>>
>>>
>>> --
>>> Simon Urli
>>> Software Engineer at XWiki SAS
>>> [email protected]
>>> More about us at http://www.xwiki.com
>
> --
> Simon Urli
> Software Engineer at XWiki SAS
> [email protected]
> More about us at http://www.xwiki.com
