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

1-) Looks an overcomplicated configuration, the framework parser should do
its work. But yes, it can be.


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>

> 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
> >

Reply via email to