[
https://issues.apache.org/jira/browse/TAP5-2808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18131858#comment-18131858
]
ASF subversion and git services commented on TAP5-2808:
-------------------------------------------------------
Commit 4fa2fb5100a3178fba0e1f79b99d543f438c4462 in tapestry-5's branch
refs/heads/property-expression-parser from Ben Weidig
[ https://gitbox.apache.org/repos/asf?p=tapestry-5.git;h=4fa2fb510 ]
TAP5-2808: Allow ranges in lists, maps and method arguments
The grammar accepted a range anywhere an expression may appear, but
the code generator rejected it below the top level. A nested range now
evaluates to an IntegerRange, and the top-level range shares the same
code path.
> PropertyConduitSourceImpl: RANGEOP not supported as sub-expression in
> lists/maps
> --------------------------------------------------------------------------------
>
> Key: TAP5-2808
> URL: https://issues.apache.org/jira/browse/TAP5-2808
> Project: Tapestry 5
> Issue Type: Bug
> Components: beanmodel
> Affects Versions: 5.9.0
> Reporter: Ben Weidig
> Priority: Minor
>
> h2. Problem
> ProperyConduitSourceImpl does not handle RANGEOP as a sub-expression, like in
> a list literal: {{[10, 20, 1..5])}}
> Attempting to create a PropertyConduit for such an expression results in a
> runtime error during conduit generation.
> h2. Grammar Vs Implementation
> The Antlr3 PropertyExpressionParser.g defines {{rangeOp}} in line 49 as a
> valid expression:
> {code}
> expression
> : keyword
> | rangeOp
> | constant
> // ... other options ...
> | list
> | map
> ;
> {code}
> The {{list}} / {{expressionList}} rules allow {{expression}}:
> {code}
> list : LBRACKET RBRACKET -> ^(LIST)
> | LBRACKET expressionList RBRACKET -> ^(LIST expressionList)
> ;
> expressionList
> : expression (COMMA! expression)*
> ;
> {code}
> However, {{PropertyConduitBuilder.implementSubexpression()}} doesn't handle
> {{RANGEOP}}.
> h2. Observed Error
> The thrown error doesn't include the (according to the grammar) valid node
> type:
> {code}
> org.apache.tapestry5.beanmodel.internal.services.PropertyExpressionException:
> Exception generating conduit for expression '[1, 1..2]': Node (.. 1 2) was
> type RANGEOP, but was expected to be (one of) DECIMAL, DEREF, FALSE,
> IDENTIFIER, INTEGER, INVOKE, LIST, NOT, NULL, SAFEDEREF, STRING, THIS, TRUE.
> at
> org.apache.tapestry5.beanmodel.internal.services.PropertyConduitSourceImpl.build(PropertyConduitSourceImpl.java:...)
> ...
> {code}
> h2. Impact and possible fix
> The grammar doesn't reflect the actual behavior.
> {{PropertyConduitSourceImpl}} should fully support the defined grammar,
> making {{RANGEOP}} usable anywhere an expression is valid, including as
> elements in lists or values in maps.
> This would require adding a handler in
> {{PropertyConduitBuilder.implementSubexpression()}} method, similar to how
> other complex types like {{LIST}} or {{MAP}} literals are handled when nested.
> This handler would be responsible for generating an
> {{org.apache.tapestry5.commons.util.IntegerRange}} instance.
> h2. Steps to Reproduce
> Attempt to create a {{PropertyConduit}} using {{PropertyConduitSource}} with
> an expression like [1, 1..5, 10] or {'myRange': 0..2}.
> h2. Current Roadblocks / Next tasks
> First attempts to implement this seems to have uncovered a Plastic bug how
> primitives are handled in certain scenarios: TAP5-2807
> The sub-expression problem came to light as I was writing tests for the
> existing grammar, so updating to Antlr 4 (TAP5-2806) would go smoothly.
> As {{PropertyConduitSourceImpl}} has to be adapted for this anyway, I won't
> attempt to implement/fix this in Antlr 3.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
