Haven't gone though you're PR, so I'm not sure how this would fit in. But I
think introducing an interface like below, and allowing it to be set may be
sufficient.
public interface ExpressionParser
{
public String convertToJavaExpression(String expression);
}
Thanks,
Tim
On Thu, Jan 14, 2016 at 12:19 AM, Chinmay Kolhatkar <[email protected]
> wrote:
> Ah got it. That's a good point. Maybe its good to separate the parsing and
> compilation part of the evaluation.
> And let one override the parsing logic.
>
> I'll see how to incorporate that, but if you have idea about achieving it,
> please share it.
>
> Thanks,
> Chinmay.
>
>
> On Thu, Jan 14, 2016 at 1:43 PM, Timothy Farkas <[email protected]>
> wrote:
>
> > Hey Chinmay,
> >
> > It is possible the user may want to define a syntax radically different
> > from Java style syntax. I've proposed a syntax similar to yours to one of
> > our users for expression evaluation but they didn't like it because the
> > syntax needs to be something easily validated by a UI. It may be possible
> > that the user wants expressions to be sent to an operator as json,
> because
> > that is easy to parse and validate in javascript:
> >
> > {"param":"myField1","operation":">","threshold":"1"}
> >
> > If the syntax is pluggable then an implementation of this syntax could be
> > swapped with with an implementation of the syntax you've already provided
> > without changing operator code.
> >
> > Thanks,
> > Tim
> >
> > On Wed, Jan 13, 2016 at 11:34 PM, Chinmay Kolhatkar <
> > [email protected]
> > > wrote:
> >
> > > Hi tim,
> > >
> > > I agree with you. The expression here we're talking about is really a
> > > quasi-Java expression. One can do anything which java does.
> > > Only change with java syntax here is how variables are accessed.
> > >
> > > They're by default accessed as ${...}.
> > >
> > > But this is also made configurable via a setter property on
> > > ExpressionEvaluator. The pull request has it.
> > >
> > > If this is what you're talking about then this is taken care of.
> > >
> > > Thanks,
> > > Chinmay.
> > >
> > >
> > > On Thu, Jan 14, 2016 at 1:00 PM, Timothy Farkas <[email protected]>
> > > wrote:
> > >
> > > > Hi Chinmay,
> > > >
> > > > I think this is a very good first implementation. My only concern is
> > that
> > > > people will get caught up in the details of the syntax for this
> > > expression
> > > > language. I think a way to avoid that is to make the syntax
> pluggable.
> > > For
> > > > example is there an interface for expression evaluation which can be
> > > > implemented by different syntaxes? This would allow operators which
> use
> > > > expression evaluation to have the syntax configured via a property.
> > That
> > > > way if someone discovers a limitation in the syntax down the line, a
> > new
> > > > syntax can be introduced without breaking backwards compatibility and
> > > > without requiring operator code to be changed.
> > > >
> > > > Thanks,
> > > > Tim
> > > >
> > > > On Wed, Jan 13, 2016 at 10:52 PM, Chinmay Kolhatkar <
> > > > [email protected]
> > > > > 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.
> > > > >
> > > > >
> > > > >
> > > >
> > >
> >
>
