apex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chinmay Kolhatkar <chin...@datatorrent.com>
Subject Re: APEXCORE-1972: ExpressionEvaluator - quasi-Java Expression Language
Date Thu, 28 Jan 2016 16:43:56 GMT
Hi Thomas,

Here is one of the usecase where quasi-Java Expression will be used.

An Expression based Enrichment operator which takes in a POJO and returns
an enriched POJO.
The output POJO fields will be configured as expressions.
The configured expressions for fields will be executed and final output
POJO will populated with result of expression.

Expression Enrichment operator can configure ExpressionEvaluator utility
with general utility functions which expression writer can directly use in
configured expression.

For eg. ExpressionEvaluator can be configured to have a "max" method and
toLower available in expression. Now expression writer can use this method
directly in expression.

Following becomes expression:
max({field1}, {field2})


Ofcourse this is just one of the usecase for this.


On Thu, Jan 28, 2016 at 9:40 PM, Thomas Weise <thomas@datatorrent.com>

> On Thu, Jan 21, 2016 at 7:22 AM, Sandeep Deshmukh <sandeep@datatorrent.com
> >
> wrote:
> >
> > 2. Supporting SQL is possible by extending the interface. Many of the
> Apex
> > users are going to be Java developers and hence supporting quasi-Java
> > expression language could be useful to them. Additionally, support for
> > for non-java developers can be considered in the next iteration of
> > expression evaluator.
> >
> >
> Why would a Java developer configure Java code as property when they can
> instead use the IDE to write the same code. It's neither convenient nor
> efficient.
> PojoUtils was created so that the non-Java developer can configure generic
> operators to assemble an application. And the syntax was intentionally
> limited because it was targeted at the non-Java user.

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