Hi Martin, > The comparison with the component queueing is because again we are going to > introduce a change that no one ever asked for
I asked for, and think I did a good job analyzing the current PropertyResolver and concluding that it's getting too complex and should be improved for better maintainability. > 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. If we have a page with conditionally visible components, it can happens that a problematic property expression goes unnoticed until we get its problematic component visible and rendered. With a parser we can detect and report syntax errors as soon as we construct a PropertyModel while initializing the page. In this case the developer would got an early exception that could otherwise go unnoticed for a long time. The benefit does exists, I will take that you think it's value is questionable. > 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. I addressed both points in my reply to Sven. > I'd like to see 8.0.0 released sooner rather than later. Me too. I have no clients under a promised Wicket 8 release date, it's my purely my personal view that Wicket 8 is the right place for proposed improvements. Pedro Santos On Tue, Jan 31, 2017 at 1:58 PM, Martin Grigorov <[email protected]> wrote: > Hi Pedro, > > On Tue, Jan 31, 2017 at 3:14 PM, Pedro Santos <[email protected]> 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 <[email protected]> >> wrote: >> > Hi Pedro, >> > >> > On Tue, Jan 31, 2017 at 10:25 AM, Pedro Santos <[email protected]> >> 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 <[email protected]> >> >> 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 < >> [email protected]> >> >> > 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 <[email protected]> >> >> 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 < >> [email protected] >> >> > >> >> >>> 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 <[email protected]> >> 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 < >> >> >>> [email protected] >> >> >>> > > >> >> >>> > >> 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 < >> >> >>> > [email protected]> >> >> >>> > >>>> 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 >> >> >>> > >>>>>> >> >> >>> > >>>>>> >> >> >>> > >>>>>> >> >> >>> > >>>>>> >> >> >>> > > >> >> >>> > >> >> >>> >> >> >> >> >> >> >> >> >>
