Allow wiki macros to update their contents and parameters upon execution

[caubin]

Hi,

This thread relates to the two JIRA issues XWIKI-18063, XWIKI-18066.

When executing wiki macros, there can be some cases where a macro would need to update its own parameters or content at execution time.
For example, a macro created with with {{myMacro paramA="1"/}} could compute the default value of another of its parameters (XWIKI-18066) or of its content (XWIKI-18063) based on the first parameter that was given.

Note that once a macro modifies its parameters (or content) during its execution, the document still has to be saved in order to persist these modifications. As such, this feature would be only useful today when macros are edited through the WYSIWYG editor of XWiki : when adding a macro in the editor, the content of the page is re-rendered, triggering the transformation of the wiki macros present in the page, which can use this opportunity to modify their content / parameters. When editing pages in wiki mode, this rendering process does not occur, and thus, the content or the parameters of the macros would stay the same. Considering that we have been pushing for the use of the WYSIWYG editor everywhere over the past years, it does not seem to be an important blocker to me.

Even though this change is not super invasive and does not require to touch the code base that much, it still impacts the transformation process of wiki macros, and needs to be carefully considered.

WDYT ?

Thanks,
Clément

[tmortagne]

(Since last time I reviewed the current implementation I thought about a security problem and reported it in the pull request).

Even if it’s a new concept from wiki macros point of view it’s something you can do in a Java based macro already so I’m +0 for this new feature (provided the security issue is fixed of course).

[surli]

@caubin

As such, this feature would be only useful today when macros are edited through the WYSIWYG editor of XWiki : when adding a macro in the editor, the content of the page is re-rendered, triggering the transformation of the wiki macros present in the page, which can use this opportunity to modify their content / parameters. When editing pages in wiki mode, this rendering process does not occur, and thus, the content or the parameters of the macros would stay the same.

This feature sounds either limited, either dangerous. Limited if you only allow to use it in WYSIWYG editor: why not using some piece of JS for achieving this in your macro then? That’s what we did for computing values in mention for example. Dangerous if we’re expanding it to any editor: it means the state of a macro is not stable, it can evolve at any rendering which can lead to a lot of problems very quickly.

So I’d be -1 for it on my side.

[caubin]

Limited if you only allow to use it in WYSIWYG editor: why not using some piece of JS for achieving this in your macro then?

The actual advantage of such solution is that we can rely on the complete XWiki API to push a different content or different parameters in the macro.

Consider the following example : a macro that can pre-fill its content with the content of a document reference given in parameter. This content can then be inline-edited using the {{wikimacrocontent/}} macro in the WYSIWYG editor (as we changed the macro content on rendering). At this point, I have no idea how such concept could be implemented through Javascript only.

It means the state of a macro is not stable, it can evolve at any rendering

Note that the change in the contents and / or the parameters of the macro would actually be interesting only in the context of a WYSIWYG editing, not when viewing a document that contains the macro. Thus, the impact of this feature is fairly limited.

All in all, I see this feature as an enabler that will allow to perform more complex operations on the long run ; I do get the idea that the feature should be carefully used, but it’s the case for most of the APIs that we expose to XWiki : it is the responsibility of the developer of the macro to actually make sure that his operations are not screwing up anything.

[vmassol]

@caubin

WDYT ?

@caubin

Even though this change is not super invasive and does not require to touch the code base that much, it still impacts the transformation process of wiki macros, and needs to be carefully considered.

Yes.

At first sight, I find this a bit dangerous/magical. You edit a document, don’t modify it and save it and then you do a diff of the revisions and you’ll suddenly see changes in the doc’s content with either parameters or content of the macro changes based on some execution context. ATM I find this too magical and too WTF for the user

@tmortagne

Even if it’s a new concept from wiki macros point of view it’s something you can do in a Java based macro already so I’m +0 for this new feature (provided the security issue is fixed of course).

Indeed, it’s possible for a java macros to do that because they can get access to the XDOM and thus make changes to it. I wonder if that’s voluntary or just because we forgot to make it read-only. I find it quite dangerous and WTF too (even if powerful for sure). Do we have examples where this is used?

So indeed I see 2 options:

1. Make the XDOM readonly for java macros and not allow wiki-based macros to change the XDOM either.
2. Allow it for both java macros and wiki macros.

Remark: This is currently already achievable in wiki macros if you use the wikimacro.context binding which gets you a MacroTransformationContext on which you can call getCurrentMacroBlock() or getXDOM(). So if we want to do 2) (still not sure about that) and since it’s an advanced use case, I’m not sure we would want to do something different than what already exist.

[tmortagne]

@vmassol

Make the XDOM readonly for java macros and not allow wiki-based macros to change the XDOM either.

We cannot do that since we have macros which rely on it (the foot note macro for example).

Also this have nothing to do with what @caubin is proposing here. The point is not at all to modify the XDOM outside of the macro but to return a modified content of the macro surrounded by the new metadata used to indicate to the WYSIWYG that this is the wiki macro content which can be modified in the content of inline editing.

[vmassol]

@tmortagne

The point is not at all to modify the XDOM outside of the macro but to return a modified content of the macro surrounded by the new metadata used to indicate to the WYSIWYG that this is the wiki macro content which can be modified in the content of inline editing.

I don’t understand this part. A Macro only has an execute() method which returns a List. How would it return something else? Using some hacks in the transformation context?

If it’s about returning something in the XDOM then you don’t need anything new since you can already control what’s returned by the macro, whether it’s a wiki macro or a java macro.

Obviously I’m missing something.