[
https://issues.apache.org/jira/browse/JEXL-438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yair Lenga updated JEXL-438:
----------------------------
Description:
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.
was:
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.
> 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
> 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)
