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
