[ https://issues.apache.org/jira/browse/VELOCITY-876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Terefang Verigorn updated VELOCITY-876: --------------------------------------- Description: Since Velocity2 is a Major version, why not start to support some new features? As of Velocity 1.x you can use ${name} to refer to object "name" in the context, or use $!{name} if you want "" for null values. How about using ${{ el-expression }} to evaluate and output the given "el-expression" in a configured el-engine with the current velocity context, same should hold for $!{{ el-expression }}. Some possible engines would be : commons-el, commons-jexl, ognl, mvel if using el/jexl ${{name}} would be mostly the same as ${name}. usage cases: the simple ${{...}} would allow more complicated expressions than present in the plain engine, especially if we look at the jexl2/3 features #if( ${{ }} ) -- would improve the boolean issue because the el could be used to wrap in "a?x:y" architecture: thru api abstraction, almost any el could be plugged in ( even groovy.eval or jsr223 ) core engine could ship with the api and el or jexl as the reference impl, other bindings would be optional jars with thier own deps. was: Since Velocity2 is a Major version, why not start to support some new features? As of Velocity 1.x you can use ${name} to refer to object "name" in the context, or use $!{name} if you want "" for null values. How about using ${{ el-expression }} to evaluate and output the given "el-expression" in a configured el-engine with the current velocity context, same should hold for $!{{ el-expression }}. Some possible engines would be : commons-el, commons-jexl, ognl, mvel if using el/jexl ${{name}} would be mostly the same as ${name}. * usage cases - the simple ${{...}} would allow more complicated expressions than present in the plain engine, especially if we look at the jexl2/3 features - #if( ${{ }} ) -- would improve the boolean issue because the el could be used to wrap in "a?x:y" * architecture thru api abstraction, almost any el could be plugged in ( even groovy.eval ) core engine could ship with the api and el or jexl as the reference impl, other bindings would be optional jars with thier own deps. > Support a Configurable EL within ${{...}} also $!{{...}} tags > ------------------------------------------------------------- > > Key: VELOCITY-876 > URL: https://issues.apache.org/jira/browse/VELOCITY-876 > Project: Velocity > Issue Type: Improvement > Components: Engine > Affects Versions: 1.7 > Reporter: Terefang Verigorn > Priority: Minor > Fix For: 2.x > > > Since Velocity2 is a Major version, why not start to support some new > features? > As of Velocity 1.x you can use ${name} to refer to object "name" in the > context, or use $!{name} if you want "" for null values. > How about using ${{ el-expression }} to evaluate and output the given > "el-expression" in a configured el-engine with the current velocity context, > same should hold for $!{{ el-expression }}. > Some possible engines would be : > commons-el, commons-jexl, ognl, mvel > if using el/jexl ${{name}} would be mostly the same as ${name}. > usage cases: > the simple ${{...}} would allow more complicated expressions than present in > the plain engine, especially if we look at the jexl2/3 features > #if( ${{ }} ) -- would improve the boolean issue because the el could be used > to wrap in "a?x:y" > architecture: > thru api abstraction, almost any el could be plugged in ( even groovy.eval or > jsr223 ) > core engine could ship with the api and el or jexl as the reference impl, > other bindings would be optional jars with thier own deps. -- This message was sent by Atlassian JIRA (v6.3.4#6332) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org