[jira] [Commented] (VELOCITY-904) Add a flag for better backward compatibility with null macro arguments
[ https://issues.apache.org/jira/browse/VELOCITY-904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16995684#comment-16995684 ] Thomas Mortagne commented on VELOCITY-904: -- OK thanks [~cbrisson] I will take that into account. > Add a flag for better backward compatibility with null macro arguments > -- > > Key: VELOCITY-904 > URL: https://issues.apache.org/jira/browse/VELOCITY-904 > Project: Velocity > Issue Type: Improvement > Components: Engine >Affects Versions: 2.0 >Reporter: Claude Brisson >Assignee: Claude Brisson >Priority: Minor > Fix For: 2.2 > > > See [this > comment|https://issues.apache.org/jira/browse/VELOCITY-542?focusedCommentId=16621819&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16621819] > : > {code} > #macro(testmacro $parameter) > $parameter > #end > #testmacro($return) > {code} > bq. which used to print "$return" (when $return is null or undefined) and we > now get "$parameter". > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Resolved] (VELOCITY-904) Add a flag for better backward compatibility with null macro arguments
[ https://issues.apache.org/jira/browse/VELOCITY-904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claude Brisson resolved VELOCITY-904. - Resolution: Fixed Fixed by 1871332. Please note that there is a small performance impact when velocimacro.arguments.preserve_literals is true, since allowing nested macro calls implies maintaining a stack of arguments literals for each argument. > Add a flag for better backward compatibility with null macro arguments > -- > > Key: VELOCITY-904 > URL: https://issues.apache.org/jira/browse/VELOCITY-904 > Project: Velocity > Issue Type: Improvement > Components: Engine >Affects Versions: 2.0 >Reporter: Claude Brisson >Assignee: Claude Brisson >Priority: Minor > Fix For: 2.2 > > > See [this > comment|https://issues.apache.org/jira/browse/VELOCITY-542?focusedCommentId=16621819&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16621819] > : > {code} > #macro(testmacro $parameter) > $parameter > #end > #testmacro($return) > {code} > bq. which used to print "$return" (when $return is null or undefined) and we > now get "$parameter". > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Comment Edited] (VELOCITY-904) Add a flag for better backward compatibility with null macro arguments
[ https://issues.apache.org/jira/browse/VELOCITY-904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16995447#comment-16995447 ] Thomas Mortagne edited comment on VELOCITY-904 at 12/13/19 8:23 AM: bq. I can't also help thinking that your use of null macro arguments is somewhat a corner case of macro usages which is very specific to xwiki, but at least it makes xwiki a good regression candidate. Yeah I'm not very proud of that either but I have to work with history unfortunately... Currently trying to think about a cleaner way to deal with this macro return need which involve a lot less hacking that people would use and which would be less impacted by Velocity internals. bq. To answer your question about what you can do to help speed up the release process, well, all the tests and regressions that you do discover are certainly helpful to improve the quality of the release, especially about backward compatibility, and we thank you for them, but I'm not sure they're making the release process faster... I must say I was not expecting to find more issues when I asked the question but yes not exactly the best to speed up the release :) was (Author: tmortagne): bq. I can't also help thinking that your use of null macro arguments is somewhat a corner case of macro usages which is very specific to xwiki, but at least it makes xwiki a good regression candidate. Yeah I'm not very proud of that either but I have to work with history unfortunately... Currently trying to think about a cleaner way to deal with this macro return need which involve a lot less hacking that people would use and which would be less impacted by Velocity internals. > Add a flag for better backward compatibility with null macro arguments > -- > > Key: VELOCITY-904 > URL: https://issues.apache.org/jira/browse/VELOCITY-904 > Project: Velocity > Issue Type: Improvement > Components: Engine >Affects Versions: 2.0 >Reporter: Claude Brisson >Assignee: Claude Brisson >Priority: Minor > Fix For: 2.2 > > > See [this > comment|https://issues.apache.org/jira/browse/VELOCITY-542?focusedCommentId=16621819&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16621819] > : > {code} > #macro(testmacro $parameter) > $parameter > #end > #testmacro($return) > {code} > bq. which used to print "$return" (when $return is null or undefined) and we > now get "$parameter". > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Comment Edited] (VELOCITY-904) Add a flag for better backward compatibility with null macro arguments
[ https://issues.apache.org/jira/browse/VELOCITY-904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16995447#comment-16995447 ] Thomas Mortagne edited comment on VELOCITY-904 at 12/13/19 8:12 AM: bq. I can't also help thinking that your use of null macro arguments is somewhat a corner case of macro usages which is very specific to xwiki, but at least it makes xwiki a good regression candidate. Yeah I'm not very proud of that either but I have to work with history unfortunately... Currently trying to think about a cleaner way to deal with this macro return need which involve a lot less hacking that people would use and which would be less impacted by Velocity internals. was (Author: tmortagne): bq. I can't also help thinking that your use of null macro arguments is somewhat a corner case of macro usages which is very specific to xwiki, but at least it makes xwiki a good regression candidate. Yeah I'm not very proud of that either but I have to work with history unfortunately... > Add a flag for better backward compatibility with null macro arguments > -- > > Key: VELOCITY-904 > URL: https://issues.apache.org/jira/browse/VELOCITY-904 > Project: Velocity > Issue Type: Improvement > Components: Engine >Affects Versions: 2.0 >Reporter: Claude Brisson >Assignee: Claude Brisson >Priority: Minor > Fix For: 2.2 > > > See [this > comment|https://issues.apache.org/jira/browse/VELOCITY-542?focusedCommentId=16621819&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16621819] > : > {code} > #macro(testmacro $parameter) > $parameter > #end > #testmacro($return) > {code} > bq. which used to print "$return" (when $return is null or undefined) and we > now get "$parameter". > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-923) Parser regression when || follow a Velocity expression
[ https://issues.apache.org/jira/browse/VELOCITY-923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16995448#comment-16995448 ] Thomas Mortagne commented on VELOCITY-923: -- As usual thanks a lot [~cbrisson] for this quick fix ! > Parser regression when || follow a Velocity expression > -- > > Key: VELOCITY-923 > URL: https://issues.apache.org/jira/browse/VELOCITY-923 > Project: Velocity > Issue Type: Bug >Affects Versions: 2.2 >Reporter: Thomas Mortagne >Assignee: Claude Brisson >Priority: Blocker > Labels: regression > Fix For: 2.2 > > > The following fail in Velocity 2.2-SNAPSHOT: > {code} > $var|| > {code} > but works fine in 1.7. > The workarounds is to put the expression inside {} (as in ${var}) > Since || is a wiki syntax in our case it's not rare to see table cells or a > link reference containing a Velocity variable (without any {} protection > since it was working well in 1.7). -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-904) Add a flag for better backward compatibility with null macro arguments
[ https://issues.apache.org/jira/browse/VELOCITY-904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16995447#comment-16995447 ] Thomas Mortagne commented on VELOCITY-904: -- bq. I can't also help thinking that your use of null macro arguments is somewhat a corner case of macro usages which is very specific to xwiki, but at least it makes xwiki a good regression candidate. Yeah I'm not very proud of that either but I have to work with history unfortunately... > Add a flag for better backward compatibility with null macro arguments > -- > > Key: VELOCITY-904 > URL: https://issues.apache.org/jira/browse/VELOCITY-904 > Project: Velocity > Issue Type: Improvement > Components: Engine >Affects Versions: 2.0 >Reporter: Claude Brisson >Assignee: Claude Brisson >Priority: Minor > Fix For: 2.2 > > > See [this > comment|https://issues.apache.org/jira/browse/VELOCITY-542?focusedCommentId=16621819&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16621819] > : > {code} > #macro(testmacro $parameter) > $parameter > #end > #testmacro($return) > {code} > bq. which used to print "$return" (when $return is null or undefined) and we > now get "$parameter". > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org