[
https://issues.apache.org/jira/browse/JEXL-438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17941268#comment-17941268
]
Henri Biestro commented on JEXL-438:
------------------------------------
I'm sorry this can't be a solution(btw, strings -single and double quoted- are
handled in this little transcoder).
However, adding a SQL-like syntax is well beyond what JEXL 'core' is meant to
be, creating a new parser and a different interpreter is certainly an
interesting - and hefty - undertaking.; you are welcome to extend JEXL's
features in a Github #pr that will encapsulate your needs.
I'll abstract how the parser is created so you can extend the Engine and I'll
make sure to review your #pr and help if I can.
> Allow alternative syntax: sql/excel-like
> ----------------------------------------
>
> Key: JEXL-438
> URL: https://issues.apache.org/jira/browse/JEXL-438
> Project: Commons JEXL
> Issue Type: New Feature
> Affects Versions: 3.4.0
> Reporter: Yair Lenga
> Priority: Major
>
> Im using jexl3 to allow customization by end users of workflow. The users
> love the flexibility, but are having repeated issues with the grammar.
> Specifically, the == operator, not having ‘<>’. I understand the parser
> cannot be configured at run time flag, as it is generated code by JavaScript,
> and changing = to mean equals will change parsing logic, operator precedence,
> etc.
> My ask: possible to allow for an alternate parser (parser-sql.jjt), which
> will be modified/extended version of the existing parser.jjt, and will
> provide more sql/excel operators. in particular, no assignment inside
> expressions, etc.
> Implementation can allow for a Boolean mode, 'Sqlish', same as 'antish'
> property. I'm not sure if possible to build a parser outside the jexl3 tree.
> If yes, will be nice to be able to pass a class that implement the same
> interface as the current parser.
> For my use case, I do not mind having all the jexl3 extension features, even
> the one not in the sql/excel grammar. I do not need the ability to have
> statements, scripts, etc.
> there are some other minor twists (concatenation, etc), but I believe those
> can be handled via jex3 operator customization. Some constructs (sql case)
> will require some additional work, but are not high priority for my use case.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
