apex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chinmay Kolhatkar <chin...@datatorrent.com>
Subject APEXCORE-1972: ExpressionEvaluator - quasi-Java Expression Language
Date Thu, 14 Jan 2016 06:52:51 GMT
Hi All,

I'm working on APEXCORE-1972 which adds support for a quasi-Java Expression
Language and its expression evaluator.

All the detailed functionality and design details along with examples are
present in Jira.

I've summarized the ExpressionEvaluator feature & Expression language below.

The pull request created for this at here:

Please share your thought on this.


*Summary of functionality of ExpressionEvaluator:*

   1. Support quasi-Java Expression which defines a single line executable
   2. Support for quasi-Java expression based function code, which will be
   compiled on the fly and made available for execution.
   3. Should support accessing multiple fields from multiples input POJOs
   while addressing the conversion of private variables to public getter
   method for all levels.
   4. Should support nested field support
   5. quasi-Java expressions should support operands to be mentioned in
   following ways:
      - ${input.fieldName}
         - Access fieldName via a object name.
      - ${fieldName}
         - Accessing fieldName directly when a single object is registered
         for operation.
      - ${input}
         - Accessing object variable directly
      - ${input.fieldName.internalField}
         - Accessing nested fields
      6. There should be some predefined function provided to expression
   writer which one can directly use in expression for invoking certain
   7. These are simple String based, Date time based etc functions.
   8. On-need-basic one should be able to easily update Expression
   Evaluator to easily add new predefined functions to be made available for
   expression writer.
   9. User of ExpressionEvaluator should be able to add a custom method
   externally to be made available to in expression.
   10. Though operands are defined, placeholder for the operand in
   expression should be allowed to be overridden. By default, expression
   language should support bash type syntax for operand - {…}
   11. The library should not introduce any serialization related issues.
   12. All the java operators should be supported.


*The examples of quasi-Java Expression:*

   - ${inp.field1}
      - Will return value of field1 from registered input POJO.
   - ${inp.field1} + ${inp.field2}
      - Will return sum of field1 & field2 from given POJO
   - ${field1} + ${field2}
      - Equivalent to above
   - ${inpA.field1} > ${inpA.field2} ? ${inpA.field3} : ${inpB.field3}
      - Executes ternary expression and returns value accordingly. Works on
      2 POJOs. inpA & inpB are two placeholder registered for given POJO with
      ExpressionEvaluator library.
   - pow(${inpA.field1}, ${inpB.field2})
      - Executes pow function coming from java.lang.Math library. This and
      other with lot other basic functions is available to expression
writer out
      of the box to use in expression.
   - ${inpA.field1} > 0 ? ${inpB.innerPOJO.field3} :
      - Shows how nested POJOs can be accessed in expression. The variables
      will evaluate to correct public getter method is required.
   - ${inp.firstname} + “ “ + ${inp.lastname}
      - Generate the full name as per given expression from firstname and
      lastname field.
   - long retVal=1; for (int i=0; ${inpF.value1}; i++) {retVal = retVal *
   ${inpF.value1}; } return retVal;
      - This tells a complete method content to ExpressionEvaluator. The
      library create an executable and compiled method using this expression.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message