[jira] [Updated] (VELOCITY-876) Support a Configurable EL within ${{...}} also $!{{...}} tags

["Terefang Verigorn (JIRA)" <ji...@apache.org>]

     [ 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-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org