Sure, working on it. Created WICKET-6318 to track the configurable property resolver implementation. Pedro Santos
On Tue, Feb 7, 2017 at 8:16 PM, Martin Grigorov <[email protected]> wrote: > Hi Pedro, > > Please create Pull Requests for your proposed changes! > Thanks! > > Martin Grigorov > Wicket Training and Consulting > https://twitter.com/mtgrigorov > > On Wed, Feb 1, 2017 at 9:00 AM, Maxim Solodovnik <[email protected]> > wrote: > >> Hello All, >> >> JFYI I have moved Apache OpenMeetings to Wicket-8 without any issues >> in ~30 minutes :) >> >> On Wed, Feb 1, 2017 at 9:04 AM, Pedro Santos <[email protected]> wrote: >> > 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 >> >>> >> >>> > >>>>>> >> >>> >> >>> > >>>>>> >> >>> >> >>> > >>>>>> >> >>> >> >>> > >>>>>> >> >>> >> >>> > > >> >>> >> >>> > >> >>> >> >>> >> >>> >> >> >> >>> >> >> >> >>> >> >> >>> >> >> >> >> -- >> WBR >> Maxim aka solomax >>
