Hi Paul,
On 18 Sep 2015 at 18:30:01, Paul Libbrecht (paul@hoplahup.net(mailto:paul@hoplahup.net))
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