[xwiki-users] Cannot use Macros as the source for an image
Hi! A few days ago I summited this as a bug http://jira.xwiki.org/browse/XRENDERING-448. I would like to thank Vincent for the quick response on it, but am a little surprised by the response and the change from "Bug" into "New Feature" request, because to me this feels like a bug in syntax precedence, where syntax tokens have a higher order of operations than the {{ }} macro syntax tokens when it should be the other way around: The macro should have higher precedence in the syntax tree and get evaluated before being used as a source for the image tag. In my opinion that would provide the most flexible and dynamic behavior for Xwiki users. Can someone on this email list share more information on the rationale behind this design decision? Thanks Regards, Francisco Peredo
On 04 May 2016, at 19:18, Peredo, Francisco <fperedo@amazon.com> wrote:
Hi!
A few days ago I summited this as a bug http://jira.xwiki.org/browse/XRENDERING-448. I would like to thank Vincent for the quick response on it, but am a little surprised by the response and the change from "Bug" into "New Feature" request, because to me this feels like a bug in syntax precedence, where syntax tokens have a higher order of operations than the {{ }} macro syntax tokens when it should be the other way around: The macro should have higher precedence in the syntax tree and get evaluated before being used as a source for the image tag. In my opinion that would provide the most flexible and dynamic behavior for Xwiki users.
Your precedence assumptions are not correct AFAIK. You could check the javacc grammar if you wish at https://github.com/xwiki/xwiki-rendering/blob/master/xwiki-rendering-wikimod...
Can someone on this email list share more information on the rationale behind this design decision?
It not a bug. It would be a bug if we had wanted to support it and it wasn’t working but since it’s never been the case it cannot be considered a bug :) Also once a syntax is defined it cannot be modified or you break backward compat. So you could imagine having support for this in a new syntax (if a grammar could be written) but it would be a new syntax and nobody from the community has expressed any interest for this. I also see a very low interest since there are other ways of doing the same thing. But if you’re willing to provide a pull request, why not (but again that would have to be a pull request for a new syntax and it would need to be proposed and agreed that the community is interested by this new syntax). Thanks -Vincent
Thanks
Regards,
Francisco Peredo
On 04 May 2016, at 20:19, Vincent Massol <vincent@massol.net> wrote:
On 04 May 2016, at 19:18, Peredo, Francisco <fperedo@amazon.com> wrote:
Hi!
A few days ago I summited this as a bug http://jira.xwiki.org/browse/XRENDERING-448. I would like to thank Vincent for the quick response on it, but am a little surprised by the response and the change from "Bug" into "New Feature" request, because to me this feels like a bug in syntax precedence, where syntax tokens have a higher order of operations than the {{ }} macro syntax tokens when it should be the other way around: The macro should have higher precedence in the syntax tree and get evaluated before being used as a source for the image tag. In my opinion that would provide the most flexible and dynamic behavior for Xwiki users.
Your precedence assumptions are not correct AFAIK. You could check the javacc grammar if you wish at https://github.com/xwiki/xwiki-rendering/blob/master/xwiki-rendering-wikimod...
Actually this is not correct. Parsing is done according the grammar and then macros are executed as a second step as a Transformation (i.e. after the XDOM has been created), see http://rendering.xwiki.org/xwiki/bin/view/Main/WebHome Thus is why rendering Macros cannot be used in the way you were imagining. In short they can never be used to generate wiki syntax parts. They can generate full syntax though. Thanks -Vincent
Can someone on this email list share more information on the rationale behind this design decision?
It not a bug. It would be a bug if we had wanted to support it and it wasn’t working but since it’s never been the case it cannot be considered a bug :) Also once a syntax is defined it cannot be modified or you break backward compat. So you could imagine having support for this in a new syntax (if a grammar could be written) but it would be a new syntax and nobody from the community has expressed any interest for this. I also see a very low interest since there are other ways of doing the same thing. But if you’re willing to provide a pull request, why not (but again that would have to be a pull request for a new syntax and it would need to be proposed and agreed that the community is interested by this new syntax).
Thanks -Vincent
Thanks
Regards,
Francisco Peredo
participants (2)
-
Peredo, Francisco -
Vincent Massol