On Mon, Oct 5, 2015 at 1:09 AM, Paul Libbrecht <p...@hoplahup.net> wrote:
> 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.
No there is no special syntax, I guess in Confluence world macro
handled are talling the parser which kind of macro they are during the
parsing. In XWiki Confluence parser there is just a hardcoded list of
known content macro right now and the default seems to be no content.
We need to make it a bit more extensible.
>
> Since, according to
> https://developer.atlassian.com/confdev/tutorials/macro-tutorials-for-confluence/creating-a-new-confluence-macro,
> "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
> _______________________________________________
> users mailing list
> users@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/users
--
Thomas Mortagne
_______________________________________________
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users
