Hello Vincent,
What failed? Reading the content. I was just saying that our Confluence parser should support macros. I’ve just tried writing a page in Confluence syntax using an existing XWiki macro and it worked:
{html}<strong>hello</strong>{html} I can't explain why this one works but I presume there's a switch internally to it that automatically converts the html macro into a closing html macro (and indeed, it's nonsense to nest html). This worked too:
{documentTree} This worked too (showing we can pass one parameter): {documentTree:checkboxes=true} Yes, parameters reading (single and multiple) worked fine (but they need escaping).
I tried a tick more formally to see if I could make a macro with content and failed. Here's how. Page: {testmacro} this is the content {testmacro} Macro: (Tools.TestMacro, object XWiki.WikiMacroClass) id: testmacro inline: no (I tried yes too, with inlined macro in the page) visibility: global macro content type: optional macro code: testMacroStart{{velocity}}$!xcontext.macro.content{{/velocity}}testMacroEnd The resulting page gives: testMacroStarttestMacroEnd this is the content testMacroStarttestMacroEnd I tried to adjust the content type to mandatory but this bragged... having no content! If macro content was thinkable, then there should be somewhere in the grammar a different mark for start and end macro or? I don't see the latter. Since, according to https://developer.atlassian.com/confdev/tutorials/macro-tutorials-for-conflu..., "there are three available body types for macros: PLAIN_TEXT, RICH_TEXT, and NONE. ", I suppose the only solution is to make the scanner read the macro content type and fork differently if mandatory (and optional?) or no content type. Maybe these two levels are a bit far from each other... Paul