Change in expression property for Wicket 8 proposal

[Pedro Santos <pe...@gmail.com>]

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

[Martijn Dashorst <ma...@gmail.com>]

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 <pe...@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



-- 
Become a Wicket expert, learn from the best: http://wicketinaction.com

Re: Change in expression property for Wicket 8 proposal

[Pedro Santos <pe...@gmail.com>]

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 <mg...@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 <pe...@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
> >
>

Re: Change in expression property for Wicket 8 proposal

[Martin Grigorov <mg...@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 <pe...@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
>