On Thu, May 9, 2019 at 4:15 PM Simon Urli <simon.u...@xwiki.com> wrote:
> Hi,
>
> On 09/05/2019 14:52, Vincent Massol wrote:
> > Hi Simon,
> >
> >> On 9 May 2019, at 09:36, Simon Urli <simon.u...@xwiki.com> wrote:
> >>
> >> Hi Vincent,
> >>
> >> On 09/05/2019 09:10, Vincent Massol wrote:
> >>> Hi Simon,
> >>>> On 7 May 2019, at 08:21, Simon Urli <simon.u...@xwiki.com> wrote:
> >>>>
> >>>> Hi everyone,
> >>>>
> >>>> I'm currently working on allowing inline editing on new wikimacros.
> >>> Why only on wikimacros? We also need to be able to edit existing
> wikimacros to make them inline-editable.
> >>
> >> of course, here I only meant that already existing macro wouldn't be
> inline editable immediately, they would require some edition for that.
> >>
> >>>> My first challenge right now is to cope with the problem of inserting
> the macro content and allowing to inline edit it.
> >>>>
> >>>> In order to do so, I propose to create two new dedicated macro:
> >>>> - wikimacrocontent: would allow to insert and inline edit a wiki
> macro content
> >>>> - wikimacroparameter: the same for a parameter.
> >>>>
> >>>> The idea would be to be able to write something such as:
> >>>>
> >>>> {{velocity}}
> >>>> {{wikimacrocontent/}}
> >>>> This is a content of $xcontext.macro.content.length() characters.
> >>>> {{/velocity}}
> >>> I don’t understand. The content is "This is a content of
> $xcontext.macro.content.length() characters.” but it’s outside of
> “{{wikimacrocontent/}}”, is this a typo?
> >>
> >> Indeed you didn't understand my example :)
> >> It was the code of the wikimacro, not the code of its usage.
> >
> > Right...
> >
> >> So if I call this macro foobar, I will execute it with something such
> as:
> >> {{foobar}}foo bar{{/foobar}}
> >>
> >> And it will ouput:
> >> foo bar
> >> This is a content of 7 characters.
> >
> > Ah yes, my bad, I mixed up the macro code content and the macro usage
> content. Indeed, I now understand that we’re trying to make changes to the
> macro usage content.
> >
> > Now we need to take into account in the design the ability to provide
> some custom mapping between what you edit and how it modifies the usage
> content.
> >
> > For example, imagine the JIRA macro when using a static list of JIRA
> issues:
> >
> > {{jira url=“…”}}
> > XWIKI-1000
> > XWIKI-1001
> > …
> > {{/jira}}
> >
> > Or Imagine the {{gallery}} macro when used with static images:
> >
> > {{gallery}}
> > img1
> > img2
> > {{/gallery}}
> >
> > In these 2 cases we’ll want some custom editors ideally and a custom
> serialization mechanism to generate back the modified content. This needs
> to be possible (pluggable) with the new APIs.
>
> Yeah I didn't mention it yet since it comes next, but it's already
> something I had in mind since Denis already has this usecase for his
> project. I need to discuss with Marius about it since it really reminds
> what has been done for the pickers, but anyway for me it should be a
> specific parameter of the macro that would be used to load a given
> widget for edition and call a script to process/transform the input to
> the expected output.
>
>
> Another thing mentioned by Denis that we should plan in the design, is
> the ability to only allow some WYSIWYG inputs for inline editing: for
> example, restricting to only inline styling, so disabling in the WYSIWYG
> editor everything's related to a new block.
>
This is already possible. See
https://github.com/xwiki-contrib/application-ckeditor/blob/master/webjar/src/main/resources/config.js#L114
. List<Block> allows everything ATM but we can introduce new "content"
types that restrict the allowed content using the allowedContent
configuration property.
> But again, for me those are features that are coming next.
>
> Simon
>
> >
> > Note that in these 2 examples I’m mentioning “static” since it’s
> possible to use Velocity script around the macro. But in this case the
> outer macro becomes the {{velocity}} macro which will be inline editable
> only as text.
> >
> > Other examples are when the macro code script parses the content and
> would like to expose only some part of it as inline editable. This requires
> a way to mark some subpart as being inline editable and a custom serializer
> to reconstruct the modified content.
> >
> >
> >> In edition the "foo bar" part will be inline editable, but not the
> "This is a content of 7 characters.".
> >> Did you mean:
> >>> {{wikimacrocontent}}
> >>> This is a content of $xcontext.macro.content.length() characters.
> >>> {{/wikimacrocontent}}
> >>> ?
> >>>> So the purpose of those macros would be twofold:
> >>>> 1. to ease the insertion of macro content/parameters (no need to
> always use {{velocity}}$xcontext.macro.content{{/velocity}}
> >>> What is $xcontext.macro.content? I’ve never used that when writing
> wiki macros.
> >>
> >> According to the doc it's currently the standard way to access the
> macro content:
> https://www.xwiki.org/xwiki/bin/view/Documentation/DevGuide/Tutorials/WritingMacros/WikiMacroTutorial/#HContent
> >>>> 2. to create the dedicated metadata around the content and to be
> processed during wikimacro rendering to allow inline editing
> >>> I don’t see any start/end. Why not:
> >>> {{inlineEditable}}
> >>> My content that is inline editable
> >>> {{/inlineEditable}}
> >>> ?
> >>> Another approach is to use scripting, as in:
> >>> $xcontext.macro.startInlineEditableContent()
> >>> My content that is inline editable
> >>> $xcontext.macro.stoptInlineEditableContent()
> >>> Or using velocity macros:
> >>> #startInlineEditableContent
> >>> My content that is inline editable
> >>> #stoptInlineEditableContent
> >>> Yet another idea would be to have a macro xclass parameter to make the
> whole content inline editable (checkbox), and the 2 approaches above would
> be when you need fine-grained details (ie not have the whole content inline
> editable).
> >>> Question: how is this done on other projects already using the concept
> of inline editable wiki macros? (I know one that I think you looked at
> Simon, but I don’t know how they did it :)).
> >>
> >> So if you're thinking about Denis' and other works about that,
> >
> > yes was thinking about this.
> >
> >> it's actually not wiki macro but Java macros. I also thought it was
> wiki macro but I was wrong. And it mainly use specific CSS classes and a
> rewrite of the CKEditor javascript to perform it.
> >
> > ok, maybe Ludovic was wrong then because I’m pretty sure he mentiopned
> that Denis was doing this with wiki macros.
> >
> > Thanks
> > -Vincent
> >
> >>
> >> Simon
> >>> Thanks
> >>> -Vincent
> >>>> Of course those macro would be only to be used inside a wikimacro.
> >>>> I started to develop the wikimacroccontent, so I have a first working
> POC, but I'd like to know WDYT about this.
> >>>>
> >>>> I would also be really happy if you could give me some wikimacro
> examples where the inline editing would make sense, so I could use it in my
> tests.
> >>>>
> >>>> Thanks,
> >>>> Simon
> >>>> --
> >>>> 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
> >
>
> --
> Simon Urli
> Software Engineer at XWiki SAS
> simon.u...@xwiki.com
> More about us at http://www.xwiki.com
>
