Hi Pedro,
PropertyResolver is very lenient currently, defining the dot (.) as a
separator of properties only - there's not much more about it.
With a custom IPropertyLocator (WICKET-5623) the following is supported too:
PropertyResolver.getValue("foo.bar.path/to/node", document);
PropertyResolver.getValue("foo.bar.attribute(name)", document);
Both are no longer valid with your proposal, because they are no valid
Java syntax or "unified EL".
IMHO this goes in the wrong direction, it takes possibilities away
instead of enabling users to customize property resolving.
I don't understand (yet) what advantage justifies this restriction. For
me a pluggable architecture is more valuable than a strict syntax.
Regards
Sven
On 31.01.2017 16:58, Martin Grigorov wrote:
Hi Pedro,
On Tue, Jan 31, 2017 at 3:14 PM, Pedro Santos <pedros...@gmail.com> wrote:
Hi Martin,
you missed the point of the proposal at [1], it's a syntax change that
would move Wicket's expression language closer to Unified Expression
Language. This change would better welcome developers used to work
with expressions like: bean.map["key"] and move Wicket closer to JSR
341 (we can continue on the linked thread).
Yes, it seems I didn't understand it right. I thought both are related -
the parser is being introduced to be able to deal with the new syntax.
The branch you pointed is the implementation of a parser to replace
your current tokenizer inside PropertyResolver.
It is not mine. It was already there when I started using Wicket.
The comparison to the component queueing is vague. It was a new
feature in Wicket 7 rather and a improvement aiming to give users
earlier syntax errors plus to improve PropertyResolver's
maintainability by replacing organic grown code with a structured
syntax tree.
The comparison with the component queueing is because again we are going to
introduce a change that no one ever asked for (well technically, Martin
Makundi asked for Component Queueing but he still uses Wicket 1.4.x
nowadays!) and this change might break many applications in production.
The parser will report errors at runtime so the developers will have to go
thru all the functionality of their apps to make sure it still works.
So the benefit is questionable! At least to me.
WICKET-4088 is created 5 years ago and since then no one ever reported any
problem related to this functionality (the map syntax).
The only related ticket I'm aware of is
https://issues.apache.org/jira/browse/WICKET-5623.
Sven made this pluggable so if the application has custom needs then it is
possible to setup custom resolver.
I'd prefer to see the new parser as a pluggable replacement too! So if it
breaks someone's application then just switch back to the old impl.
So I'm -0 on this improvement but let's see what others think too!
I'd like to see 8.0.0 released sooner rather than later.
I understand and share your concern about maintenance. It's my
understand that the entire team signs a release, and that we all can
support and maintain the features inside it. I will understand if
anyone stops this improvement based on cost/benefit analysis or on the
merit that it's hard to maintain a parser. I do not share such
concerns and pointed out the benefits of such improvement at [2] (we
can continue on the linked thread).
1 - http://wicket-dev.markmail.org/thread/unwdqpxulw7tcd5l
2 - http://markmail.org/message/yc2pwmbmasx5rzim
On Tue, Jan 31, 2017 at 10:13 AM, Martin Grigorov <mgrigo...@apache.org>
wrote:
Hi Pedro,
On Tue, Jan 31, 2017 at 10:25 AM, Pedro Santos <pedros...@gmail.com>
wrote:
Hi Martin,
Wicket-4201 IPageProvider improvement: will work on the ticket during
the
week
Expression language change [1]: it's a big change and I think it needs
the team approval
Here is the diff:
https://github.com/apache/wicket/compare/WICKET-4008-
property-expression-parser
Wicket-4008 expression language parser: the parser is functional and
there isn't much work pending on it. I can finish and merge the work
during the week.
1 - http://wicket-dev.markmail.org/thread/unwdqpxulw7tcd5l
The linked discussion makes me feel a bit uncertain.
I want to avoid another "component queueing" case here, i.e. a rather
bigger refactoring for something that only few people asked for and then
leave the maintenance to someone else. The fact that you didn't have time
to work on these changes in the last few months makes me think you may
not
have time to answer questions and fix bugs once it is released. No one
can
guarantee that (s)he will be around to help with his/her expertize, me
included, but if you know from now that you won't have time then maybe it
would be better to not make these changes.
I agree that the team should decide so anyone is welcome to express his
opinion!
Pedro Santos
On Thu, Jan 12, 2017 at 9:08 PM, Martin Grigorov <mgrigo...@apache.org>
wrote:
Hi,
@Sven: have you started migrating your app ?
@Pedro: any idea when you will have time to finish your improvements?
Do
you need any help ?
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov
On Mon, Nov 21, 2016 at 11:54 AM, Martin Grigorov <
mgrigo...@apache.org>
wrote:
Probably we should stick to the principle: If it works, don't touch
it!
This is related to CGLib and ClassMetaCache
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov
On Mon, Nov 21, 2016 at 1:22 AM, Pedro Santos <pedros...@gmail.com>
wrote:
We can replace ClassMetaCache used in wicket-ioc's Injector by a
Jandex[1]
class index.
1 - https://github.com/wildfly/jandex
Pedro Santos
On Sun, Nov 20, 2016 at 4:19 PM, Martin Grigorov <
mgrigo...@apache.org
wrote:
The main advantages of ByteBuddy are:
- actively developed
- Mockito 2 moved to it
- Hibernate 5.x is moving to it (
https://twitter.com/vlad_mihalcea/status/798971296910483456)
- Spring considers it (they actually already use it for the tests:
https://twitter.com/ankinson/status/799363435775586308)
- support for Java 9 (we will need it at some point)
- support for Android (I guess no one will ever run Wicket inside
Android,
but who knows)
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov
On Sun, Nov 20, 2016 at 7:08 PM, Sven Meier <s...@meiers.net>
wrote:
Replace CGLIB with ByteBuddy because it has better support for
Java 8
and 9
What are the advantages? Seems Spring hasn't decided on this
yet:
https://jira.spring.io/browse/SPR-8190
Regards
Sven
On 20.11.2016 00:47, Martin Grigorov wrote:
Replace CGLIB with ByteBuddy because it has better support for
Java 8
and
9
?
CGLIB could stay as fallback (via system property) until 9.0.0.
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov
On Fri, Nov 18, 2016 at 12:49 PM, Andrea Del Bene <
an.delb...@gmail.com
wrote:
yah, I think it's better
On 14/11/2016 19:54, Martin Grigorov wrote:
+1
Maybe rename #forResource() to #of() ?
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov
On Fri, Nov 11, 2016 at 5:00 PM, Andrea Del Bene <
an.delb...@gmail.com>
wrote:
I'm wondering if there is room for an improvement for
ResourceReference,
introducing lambda support also for this component. Actually
it's
something
that can be done after the release of 8.0.0, but I'd like to
collect
your
feedback anyway. The idea is to provide factory methods to
build a
ResourceReference using lambdas and avoiding anonymous
classes
to
implement
getResource().
The following snippet should better explain what I mean:
https://gist.github.com/bitstorm/
03cfe9905a3f86a7160ab49f0ce23f13
Andrea.
On 31/10/2016 14:41, Martin Grigorov wrote:
Hi,
What other improvements do we need in 8.x/master before
promoting it
to
8.0.0 final ?
At https://cwiki.apache.org/confluence/display/WICKET/
Ideas+
for+Wicket+8.0
we still have:
- new DateTime APIs for wicket-datetime *WICKET-6105
<https://issues.apache.org/jira/browse/WICKET-6105>* -
I'll
give
this
one
more try but the problem is that I don't believe this is
the
proper
way
and
this demotivates me.
If someone else wants to give it a try - please assign it
to
yourself!
- Better SEO for stateful pages - the only way I see this
is
by
using
ServiceWorker to add the pageId as a request header to all
requests
(normal
& Ajax)
Recently I wondered whether Redux.js could be in use for
Wicket.
I don't have much experience with it, but both React and
AngularJs
communities use it to manage the state for their
components.
There are some Java impls, even a standard is coming:
https://github.com/jvm-redux/jvm-redux-api
What else ?
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov
