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