Hi Paul, On 18 Sep 2015 at 18:30:01, Paul Libbrecht ([email protected](mailto:[email protected])) wrote:
Hello Vincent,
so it should work fine. I also see in ConfluenceWikiScanner.splitMacroParams() the code to split the parameters. Nope, it failed.
What failed? 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} This worked too: {documentTree} This worked too (showing we can pass one parameter): {documentTree:checkboxes=true} This worked too (showing you can pass more than 1 parameter): {documentTree:checkboxes=true|root=space:xwiki:Blog}
What worked is to read a parameter or make it an {html} macro though: - {jsmath:f=\\frac\{x\}\{x+3\}} - {html}\( \frac{x+3}{x} \){html} The first, however, is a plague to use because of th eneed to escape all curly brackets.
Note: It’s still interesting to me to make macros work well in the confluence syntax so if you want to continue on that path I’m happy to help as I can. is it useful to document it somewhere? where?
What would you wish to document? The Confluence syntax? If so I think we should point to some reference page from the Atlassian site instead (putting a link here: http://rendering.xwiki.org/xwiki/bin/view/Main/WebHome#HSupportedSyntaxes).
That's easy enough to keep it in Confluence for now.
Now I’d recommend that once you have a page in Confluence syntax inside XWiki, you convert it to XWiki Syntax 2.1 and then you won’t have any problem in using any wiki macro or the WYSIWYG editor and all features of XWiki in general. Good point. I'll keep that in mind as the next step.
BTW do you know that we have a Confluence importer? :) I know it but the confluence I import from is a version 3 and apparently, confluence version 4 and 5 cannot import xml exports of version 3. This importer seems to be focussed on version 5 which is the latest and it's good this way.
Ok, didn’t know about your version and the one our importer supports.
I wonder if such importers should not stay at the level of scripting code which others hack.
Are you referring to our Confluence importer? Do you mean not writing our official importer in java but instead in script in wiki pages?
My little solution works just for me and that's fine this way... and probably improters will be this way for a long time.
Thanks -Vincent
Paul