[
https://issues.apache.org/jira/browse/JEXL-438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro resolved JEXL-438.
--------------------------------
Resolution: Fixed
Commit
[8c92134|https://github.com/apache/commons-jexl/commit/8c9213493fda554a075627dea59da29834035082]
> Allow parser factory specification
> ----------------------------------
>
> 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
> Assignee: Henri Biestro
> Priority: Major
> Fix For: 3.4.1
>
>
> 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)
