I have few concerns regarding the proposal, so my vote is -0 till they
are resolved
1. Usage of quasi-Java proprietary language. Even though most of the
syntax adheres to Java, usage of ${} invalidates ability to use general
IDEs to develop expressions. Debugging and verifying correctness of any
complex expression becomes a non trivial task for application developers.
2. What other languages were considered for expressions? Why quasi-Java
was selected in favor of for example SQL syntax?
3. Separating imports from expressions seems as inconvenience to
expression developers to me. Why imports can't be specified as part of
expression definition?
4. Where multiple POJOs come from? If assumption is that different POJOs
come from different input ports, how tuples from different ports are
synchronized?
5. Are we supporting both POJOUtils and ExpressionEvaluator? If not,
what is the plan to deprecate POJOUtils? If yes, syntax of POJOUtils and
ExpressionEvaluator don't seem to be compatible.
6. POJOUtils supports both getters and setters, what is the plan to
support setters in ExpressionEvaluator?
Thank you,
Vlad
On 1/13/16 22:52, Chinmay Kolhatkar wrote:
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:
https://github.com/apache/incubator-apex-malhar/pull/170
Please share your thought on this.
Thanks,
Chinmay.
*Summary of functionality of ExpressionEvaluator:*
1. Support quasi-Java Expression which defines a single line executable
expression
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
functionality.
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} :
${inpA.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.
