Hi Martin, sure! I guess you mean the parser I'm developing int the WICKET-4008 branch. Just want to clear that this proposal has no relation with the parser. As Martijn, I have mixed feelings regarding this proposal, for the same reasons.
Regarding the parser that I will propose and am developing in WICKET-4008 branch, 1-) Looks an overcomplicated configuration, the framework parser should do its work. But yes, it can be. 2-) The parser only parses the expression to better explain syntax errors and to provide PropertyResolver with an analyzed input that meaningful and easier to navigate (not implemented yet). Plus will allow us to remove parsing logic mixed in the expression resolution code, like PropertyResolver#getNextDotIndex and its usages in through the code. My guess is that the fancy properties of the language are barely used. "[" is pretty much a reserved character right now and to simply have it inside square bracket would be enough to cause problems. Plus a simple empty space inside the method call brackets like "method( )" would fail without even informing that the method call syntax wasn't accepted/valid. I'm already open tickets to track those problems regardless of how we choose to parse the expression. I'm not using map key in the grammar nor in the parser implementation, maybe in the test cases which is OK. You are right, the index should be identified as a list/array position or as a map key during the property expression resolution inside PropertyResolver, not by the parser. Pedro Santos On Thu, Sep 22, 2016 at 4:25 PM, Martin Grigorov <mgrigo...@apache.org> wrote: > Hi Pedro, > > There were no complains about the current parser, but that doesn't mean we > should not improve! > > Two questions: > 1) can it be switchable? i.e. if someone faces a problem with the new > parser then by using a JVM setting (-Dxyz=...) to switch to the old parser > 2) does it cover all current funtionality ? I don't use fancy property > expressions in my apps but I remember seeing support for array and list > indexing. Your branch talks about map keys but since the syntax is the same > maybe it is already supported. But if it is then the index should be parsed > to int at the usage side. > > > Martin Grigorov > Wicket Training and Consulting > https://twitter.com/mtgrigorov > > On Wed, Sep 21, 2016 at 2:30 AM, Pedro Santos <pedros...@gmail.com> wrote: > > > Hi devs, > > > > currently we can't have expression properties for map keys containing the > > '[' character, even though it's a valid key character. My proposal is to > > change our current string literal to a quoted one. So the expression > > *map[myKey]* would no longer be valid in benefit of *map["myKey"]* or > > *map['myKey']*. Any quote and escape character would need to be escaped, > > and I suggest us to use the same escape logic from the Unified Expression > > Language [1] and the original OGNL[2]. > > > > 1 - http://docs.oracle.com/javaee/5/tutorial/doc/bnahq.html#bnahu > > 2 - http://commons.apache.org/proper/commons-ognl/language-guide.html > > > > cheers > > > > Pedro Santos > > >
