Re: Change in expression property for Wicket 8 proposal
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 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 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 > > >
Re: Change in expression property for Wicket 8 proposal
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 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 >
Re: Change in expression property for Wicket 8 proposal
Interesting. I don't have a preference. I don't like breaking existing applications, and I like adhering to common usage or specs. Martijn On Wed, Sep 21, 2016 at 2:30 AM, Pedro Santos 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 -- Become a Wicket expert, learn from the best: http://wicketinaction.com
Change in expression property for Wicket 8 proposal
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