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 <solomax...@gmail.com> 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 <pedros...@gmail.com> 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 <mgrigo...@apache.org> > 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 > >>> >> >>> > >>>>>> > >>> >> >>> > >>>>>> > >>> >> >>> > >>>>>> > >>> >> >>> > >>>>>> > >>> >> >>> > > > >>> >> >>> > > >>> >> >>> > >>> >> >> > >>> >> >> > >>> >> > >>> > > > > -- > WBR > Maxim aka solomax >
