Ben Weidig created TAP5-2808:
--------------------------------
Summary: 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
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
(v8.20.10#820010)
