There is 1 update.
 
 
XWiki Rendering / cid:jira-generated-image-avatar-82b8a5c3-b48e-4aaf-aecf-f82a365b336d XRENDERING-747 Open

Support converting/changing macros during the macro transformation

 
View issue   ·   Add comment
 

1 update

 
cid:jira-generated-image-avatar-98fb5a9a-6547-44e9-9788-f852a6c6c7a4 Changes by Raphaël Jakse on 07/Jun/24 09:28
 
Description: It would sometimes be useful to have a way to "seamlessly" convert a macro (its name and/ or its parameters (names and values)) in some way before it is executed in the macro transformation. As an example, imagine a

Here are two motivational examples:
* A "legacy"
macro transitions from having takes two field for specifying parameters: a document and an attachment name . Now that we have attachment references, the macro is updated to having a single field for be able to take only one parameter: an attachment reference. For backward compatibility reasons, the implementation can support both, however the new way is better for several reasons. In that case, it would be nice if the macro could, before it is executed, transform these two parameters into one such that this change is persisted in the macro marker block.
* We import content from a wiki that features macros. To be sure to not lose information and accidentally hit incompatible macros with the same name in XWiki, we prefix all these macros. A few months later, one such macro, we happen to implement interestingfeature in XWiki, and theotherwiki_interestingfeature happens to look very similar (prehaps because we took inspiration and intended interrestingfeature to look like theotherwiki_interestingfeature). Seamlessly converting it to nicefeature would be nice.  

This should have the following consequences:
# The macro execution itself directly gets the new parameter.
# When editing the macro in the WYSIWYG editor, the user sees the converted
parameter parameters and the inputs for the legacy parameters can be removed.
# When saving after editing in the WYSIWYG editor, the new parameter value(s) are saved.

In the same way, a macro should be able to indicate a macro it should be replaced with and perform a conversion of the parameters of the replacement. There should probably still be macros with both the old and the new name to handle things like execution priority but - depending on the actual implementation - the "old" macro might never be executed.

The easiest way to implement this would probably be some kind of preprocessing method in macros themselves (similar to the current prepare method, but with a guarantee that it will be executed and a way to change the macro's id), but this could also be implemented as a separate macro converter component.


There should be a way to reject the transformation, for instance if there are parameters, or parameter values, in the macro to convert that are not supported yet in the target macro.