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-confl…,
"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