[ 
https://issues.apache.org/jira/browse/JEXL-438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17945026#comment-17945026
 ] 

Henri Biestro commented on JEXL-438:
------------------------------------

It will be available in 3.5.0 (release vote is underway); there is no 3.4.1 
since we've added feature to 3.4 - micro version is for maintenance only / bug 
fixing.

> 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.5.0
>
>
> 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)

Reply via email to