You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wicket.apache.org by Martin Grigorov <mg...@apache.org> on 2017/01/12 23:08:46 UTC
Re: What else do we want to do before 8.0.0 final ?
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 <mg...@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 <pe...@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 <mg...@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 <sv...@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.delbene@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.delbene@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
>> > >>>>>>
>> > >>>>>>
>> > >>>>>>
>> > >>>>>>
>> > >
>> >
>>
>
>
Re: What else do we want to do before 8.0.0 final ?
Posted by Sven Meier <sv...@meiers.net>.
Hi Andrea,
my bad, this project here still uses the predecessor o_O
I'll switch to wicketstuff-select2 now.
Thanks
Sven
On 16.01.2017 17:19, Andrea Del Bene wrote:
>
>
> On 16/01/2017 17:14, Sven Meier wrote:
>> Hi,
>>
>> ok, found some time to continue my migration:
>>
>> We will have to migrate select2 to wicket-8.x because of WICKET-6137.
>>
>> Anyone working on this already? Otherwise I'll do it tomorrow.
>
> I don't know if it can help, but the select2 from WicketStuff master
> branch works correctly.
>
>>
>> Have fun
>> Sven
>>
>>
>>
>> On 13.01.2017 07:59, Maxim Solodovnik wrote:
>>> Hello Sven,
>>>
>>> please let me know if select2 need to be fixed/improved :)
>>>
>>> On Fri, Jan 13, 2017 at 1:54 PM, Sven Meier <sv...@meiers.net> wrote:
>>>> Hi Martin,
>>>>
>>>> yes, I gave it a shot this week:
>>>>
>>>> From 6.x to 8.x in one step with ~400 compile errors, mainly
>>>> related to
>>>> AjaxRequestTarget and ExportableColumn.
>>>>
>>>> I didn't have time to finish the migration when select2 showed some
>>>> weird
>>>> class hierarchy errors,
>>>> but I don't expect it to take me more than two days in total.
>>>>
>>>> I'll keep you all updated
>>>> Sven
>>>>
>>>>
>>>> On 13.01.2017 00:08, Martin Grigorov 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
>>>>> <mg...@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 <pe...@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
>>>>>>> <mg...@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 <sv...@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.delbene@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.delbene@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
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>
>>>
>>
>
Re: What else do we want to do before 8.0.0 final ?
Posted by Andrea Del Bene <an...@gmail.com>.
On 16/01/2017 17:14, Sven Meier wrote:
> Hi,
>
> ok, found some time to continue my migration:
>
> We will have to migrate select2 to wicket-8.x because of WICKET-6137.
>
> Anyone working on this already? Otherwise I'll do it tomorrow.
I don't know if it can help, but the select2 from WicketStuff master
branch works correctly.
>
> Have fun
> Sven
>
>
>
> On 13.01.2017 07:59, Maxim Solodovnik wrote:
>> Hello Sven,
>>
>> please let me know if select2 need to be fixed/improved :)
>>
>> On Fri, Jan 13, 2017 at 1:54 PM, Sven Meier <sv...@meiers.net> wrote:
>>> Hi Martin,
>>>
>>> yes, I gave it a shot this week:
>>>
>>> From 6.x to 8.x in one step with ~400 compile errors, mainly
>>> related to
>>> AjaxRequestTarget and ExportableColumn.
>>>
>>> I didn't have time to finish the migration when select2 showed some
>>> weird
>>> class hierarchy errors,
>>> but I don't expect it to take me more than two days in total.
>>>
>>> I'll keep you all updated
>>> Sven
>>>
>>>
>>> On 13.01.2017 00:08, Martin Grigorov 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
>>>> <mg...@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 <pe...@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
>>>>>> <mg...@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 <sv...@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.delbene@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.delbene@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
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>
>>
>
Re: What else do we want to do before 8.0.0 final ?
Posted by Sven Meier <sv...@meiers.net>.
Hi,
ok, found some time to continue my migration:
We will have to migrate select2 to wicket-8.x because of WICKET-6137.
Anyone working on this already? Otherwise I'll do it tomorrow.
Have fun
Sven
On 13.01.2017 07:59, Maxim Solodovnik wrote:
> Hello Sven,
>
> please let me know if select2 need to be fixed/improved :)
>
> On Fri, Jan 13, 2017 at 1:54 PM, Sven Meier <sv...@meiers.net> wrote:
>> Hi Martin,
>>
>> yes, I gave it a shot this week:
>>
>> From 6.x to 8.x in one step with ~400 compile errors, mainly related to
>> AjaxRequestTarget and ExportableColumn.
>>
>> I didn't have time to finish the migration when select2 showed some weird
>> class hierarchy errors,
>> but I don't expect it to take me more than two days in total.
>>
>> I'll keep you all updated
>> Sven
>>
>>
>> On 13.01.2017 00:08, Martin Grigorov 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 <mg...@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 <pe...@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 <mg...@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 <sv...@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.delbene@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.delbene@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
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>
>
Re: What else do we want to do before 8.0.0 final ?
Posted by Maxim Solodovnik <so...@gmail.com>.
Hello Sven,
please let me know if select2 need to be fixed/improved :)
On Fri, Jan 13, 2017 at 1:54 PM, Sven Meier <sv...@meiers.net> wrote:
> Hi Martin,
>
> yes, I gave it a shot this week:
>
> From 6.x to 8.x in one step with ~400 compile errors, mainly related to
> AjaxRequestTarget and ExportableColumn.
>
> I didn't have time to finish the migration when select2 showed some weird
> class hierarchy errors,
> but I don't expect it to take me more than two days in total.
>
> I'll keep you all updated
> Sven
>
>
> On 13.01.2017 00:08, Martin Grigorov 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 <mg...@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 <pe...@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 <mg...@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 <sv...@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.delbene@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.delbene@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
Re: What else do we want to do before 8.0.0 final ?
Posted by Sven Meier <sv...@meiers.net>.
Hi Martin,
yes, I gave it a shot this week:
From 6.x to 8.x in one step with ~400 compile errors, mainly related to
AjaxRequestTarget and ExportableColumn.
I didn't have time to finish the migration when select2 showed some
weird class hierarchy errors,
but I don't expect it to take me more than two days in total.
I'll keep you all updated
Sven
On 13.01.2017 00:08, Martin Grigorov 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 <mg...@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 <pe...@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 <mg...@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 <sv...@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.delbene@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.delbene@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
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>
Re: What else do we want to do before 8.0.0 final ?
Posted by Tobias Soloschenko <to...@googlemail.com.INVALID>.
Hi,
great to hear and thanks for the feedback. :-)
kind regards
Tobias
> Am 01.02.2017 um 09:00 schrieb Maxim Solodovnik <so...@gmail.com>:
>
> Hello All,
>
> JFYI I have moved Apache OpenMeetings to Wicket-8 without any issues
> in ~30 minutes :)
Re: What else do we want to do before 8.0.0 final ?
Posted by Pedro Santos <pe...@gmail.com>.
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 <mg...@apache.org> 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 <so...@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 <pe...@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 <mg...@apache.org>
>> wrote:
>> >> Hi Pedro,
>> >>
>> >> On Tue, Jan 31, 2017 at 3:14 PM, Pedro Santos <pe...@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 <
>> mgrigorov@apache.org>
>> >>> wrote:
>> >>> > Hi Pedro,
>> >>> >
>> >>> > On Tue, Jan 31, 2017 at 10:25 AM, Pedro Santos <pe...@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 <
>> mgrigorov@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 <
>> >>> mgrigorov@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 <
>> pedrosans@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 <
>> >>> mgrigorov@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 <sv...@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.delbene@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.delbene@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
>>
Re: What else do we want to do before 8.0.0 final ?
Posted by Martin Grigorov <mg...@apache.org>.
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 <so...@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 <pe...@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 <mg...@apache.org>
> wrote:
> >> Hi Pedro,
> >>
> >> On Tue, Jan 31, 2017 at 3:14 PM, Pedro Santos <pe...@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 <
> mgrigorov@apache.org>
> >>> wrote:
> >>> > Hi Pedro,
> >>> >
> >>> > On Tue, Jan 31, 2017 at 10:25 AM, Pedro Santos <pe...@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 <
> mgrigorov@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 <
> >>> mgrigorov@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 <
> pedrosans@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 <
> >>> mgrigorov@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 <sv...@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.delbene@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.delbene@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
>
Re: What else do we want to do before 8.0.0 final ?
Posted by Maxim Solodovnik <so...@gmail.com>.
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 <pe...@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 <mg...@apache.org> wrote:
>> Hi Pedro,
>>
>> On Tue, Jan 31, 2017 at 3:14 PM, Pedro Santos <pe...@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 <mg...@apache.org>
>>> wrote:
>>> > Hi Pedro,
>>> >
>>> > On Tue, Jan 31, 2017 at 10:25 AM, Pedro Santos <pe...@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 <mg...@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 <
>>> mgrigorov@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 <pe...@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 <
>>> mgrigorov@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 <sv...@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.delbene@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.delbene@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
Re: What else do we want to do before 8.0.0 final ?
Posted by Pedro Santos <pe...@gmail.com>.
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 <mg...@apache.org> wrote:
> Hi Pedro,
>
> On Tue, Jan 31, 2017 at 3:14 PM, Pedro Santos <pe...@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 <mg...@apache.org>
>> wrote:
>> > Hi Pedro,
>> >
>> > On Tue, Jan 31, 2017 at 10:25 AM, Pedro Santos <pe...@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 <mg...@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 <
>> mgrigorov@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 <pe...@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 <
>> mgrigorov@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 <sv...@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.delbene@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.delbene@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
>> >> >>> > >>>>>>
>> >> >>> > >>>>>>
>> >> >>> > >>>>>>
>> >> >>> > >>>>>>
>> >> >>> > >
>> >> >>> >
>> >> >>>
>> >> >>
>> >> >>
>> >>
>>
Re: What else do we want to do before 8.0.0 final ?
Posted by Pedro Santos <pe...@gmail.com>.
Hi Sven,
> PropertyResolver is very lenient currently, defining the dot (.) as a separator of properties only - there's not much more about it.
There is. Take the expression "a.b.c", there's no guarantee Wicket's
tokenizer will break it only by dots. A custom IPropertyLocator
currently has to handle possible scenarios where the tokens are "a.b"
+ "c" or "a" + "b.c". Plus there's a dot escaping logic that won't
allow a user to express a map value if its key contains a closing
bracket followed by a dot; as explained in WICKET-6247 and a possible
solution being Wicket's expression language syntax change proposed in
[1].
You and Martin have a good point saying the architecture should be
pluggable or configurable. Both use cases you pointed should be able
to be supported by a custom implementation of a pluggable property
resolver, and not as a one more complexity in an already tangled and
all purpose resolver as PropertyResolver has grown to be. Rather than
to open PropertyResolver to custom IPropertyLocator implementations,
we should open the Application to custom PropertyResolver
implementations. So even an expression language that is not as unique
as Wicket's one would have it's place.
> Both are no longer valid with your proposal, because they are no valid Java syntax or "unified EL".
The parser aims to be the default implementation offering early and
meaningful syntax errors plus offering the resolver a structured
syntax tree to work on. I invite the team to read
DefaultPropertyLocator's implementation to get the importance of it.
The parser wasn't meant to invalidate any other syntax and I would
support the choice to have a configurable resolver implementation in
the Application rather the current complex all purpose and
configurable resolver that only work for very specific dot tokenizer
logic.
> I don't understand (yet) what advantage justifies this restriction. For me a pluggable architecture is more valuable than a strict syntax.
Sure, my point is let's make the it pluggable in a better place and
the default resolver to be a simpler syntax closer to the standard
JSR-341.
1 - http://wicket-dev.markmail.org/thread/unwdqpxulw7tcd5l
Pedro Santos
On Tue, Jan 31, 2017 at 7:59 PM, Sven Meier <sv...@meiers.net> wrote:
> Hi Pedro,
>
> PropertyResolver is very lenient currently, defining the dot (.) as a
> separator of properties only - there's not much more about it.
>
> With a custom IPropertyLocator (WICKET-5623) the following is supported too:
>
> PropertyResolver.getValue("foo.bar.path/to/node", document);
> PropertyResolver.getValue("foo.bar.attribute(name)", document);
>
> Both are no longer valid with your proposal, because they are no valid Java
> syntax or "unified EL".
> IMHO this goes in the wrong direction, it takes possibilities away instead
> of enabling users to customize property resolving.
>
> I don't understand (yet) what advantage justifies this restriction. For me a
> pluggable architecture is more valuable than a strict syntax.
>
> Regards
> Sven
>
>
>
> On 31.01.2017 16:58, Martin Grigorov wrote:
>>
>> Hi Pedro,
>>
>> On Tue, Jan 31, 2017 at 3:14 PM, Pedro Santos <pe...@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 <mg...@apache.org>
>>> wrote:
>>>>
>>>> Hi Pedro,
>>>>
>>>> On Tue, Jan 31, 2017 at 10:25 AM, Pedro Santos <pe...@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 <mg...@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 <
>>>
>>> mgrigorov@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 <pe...@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 <
>>>
>>> mgrigorov@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 <sv...@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.delbene@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.delbene@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
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>
>
Re: What else do we want to do before 8.0.0 final ?
Posted by Sven Meier <sv...@meiers.net>.
Hi Pedro,
PropertyResolver is very lenient currently, defining the dot (.) as a
separator of properties only - there's not much more about it.
With a custom IPropertyLocator (WICKET-5623) the following is supported too:
PropertyResolver.getValue("foo.bar.path/to/node", document);
PropertyResolver.getValue("foo.bar.attribute(name)", document);
Both are no longer valid with your proposal, because they are no valid
Java syntax or "unified EL".
IMHO this goes in the wrong direction, it takes possibilities away
instead of enabling users to customize property resolving.
I don't understand (yet) what advantage justifies this restriction. For
me a pluggable architecture is more valuable than a strict syntax.
Regards
Sven
On 31.01.2017 16:58, Martin Grigorov wrote:
> Hi Pedro,
>
> On Tue, Jan 31, 2017 at 3:14 PM, Pedro Santos <pe...@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 <mg...@apache.org>
>> wrote:
>>> Hi Pedro,
>>>
>>> On Tue, Jan 31, 2017 at 10:25 AM, Pedro Santos <pe...@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 <mg...@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 <
>> mgrigorov@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 <pe...@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 <
>> mgrigorov@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 <sv...@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.delbene@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.delbene@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
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>
Re: What else do we want to do before 8.0.0 final ?
Posted by Martin Grigorov <mg...@apache.org>.
Hi Pedro,
On Tue, Jan 31, 2017 at 3:14 PM, Pedro Santos <pe...@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 <mg...@apache.org>
> wrote:
> > Hi Pedro,
> >
> > On Tue, Jan 31, 2017 at 10:25 AM, Pedro Santos <pe...@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 <mg...@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 <
> mgrigorov@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 <pe...@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 <
> mgrigorov@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 <sv...@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.delbene@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.delbene@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
> >> >>> > >>>>>>
> >> >>> > >>>>>>
> >> >>> > >>>>>>
> >> >>> > >>>>>>
> >> >>> > >
> >> >>> >
> >> >>>
> >> >>
> >> >>
> >>
>
Re: What else do we want to do before 8.0.0 final ?
Posted by Pedro Santos <pe...@gmail.com>.
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).
The branch you pointed is the implementation of a parser to replace
your current tokenizer inside PropertyResolver.
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.
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 <mg...@apache.org> wrote:
> Hi Pedro,
>
> On Tue, Jan 31, 2017 at 10:25 AM, Pedro Santos <pe...@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 <mg...@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 <mg...@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 <pe...@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 <mgrigorov@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 <sv...@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.delbene@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.delbene@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
>> >>> > >>>>>>
>> >>> > >>>>>>
>> >>> > >>>>>>
>> >>> > >>>>>>
>> >>> > >
>> >>> >
>> >>>
>> >>
>> >>
>>
Re: What else do we want to do before 8.0.0 final ?
Posted by Martin Grigorov <mg...@apache.org>.
Hi Pedro,
On Tue, Jan 31, 2017 at 10:25 AM, Pedro Santos <pe...@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 <mg...@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 <mg...@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 <pe...@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 <mgrigorov@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 <sv...@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.delbene@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.delbene@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
> >>> > >>>>>>
> >>> > >>>>>>
> >>> > >>>>>>
> >>> > >>>>>>
> >>> > >
> >>> >
> >>>
> >>
> >>
>
Re: What else do we want to do before 8.0.0 final ?
Posted by Pedro Santos <pe...@gmail.com>.
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
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
Pedro Santos
On Thu, Jan 12, 2017 at 9:08 PM, Martin Grigorov <mg...@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 <mg...@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 <pe...@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 <mg...@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 <sv...@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.delbene@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.delbene@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
>>> > >>>>>>
>>> > >>>>>>
>>> > >>>>>>
>>> > >>>>>>
>>> > >
>>> >
>>>
>>
>>
Re: What else do we want to do before 8.0.0 final ?
Posted by Martijn Dashorst <ma...@gmail.com>.
I would like to add Sub Resource Integrity [1] to HeaderItems, similar
to what getbootstrap.com advocates on their links. For URL based
resource references this would mean an API addition, but for classpath
based resources we could generate the hashes ourselves.
<link rel="stylesheet"
href="https://maxcdn.bootstrapcdn.com/bootstrap/3.3.7/css/bootstrap.min.css"
integrity="sha384-BVYiiSIFeK1dGmJRAkycuHAHRg32OmUcww7on3RYdg4Va+PmSTsz/K68vbdEjh4u"
crossorigin="anonymous">
<!-- Optional theme -->
<link rel="stylesheet"
href="https://maxcdn.bootstrapcdn.com/bootstrap/3.3.7/css/bootstrap-theme.min.css"
integrity="sha384-rHyoN1iRsVXV4nD0JutlnGaslCJuC7uwjduW9SVrLvRYooPp2bWYgmgJQIXwl/Sp"
crossorigin="anonymous">
<!-- Latest compiled and minified JavaScript -->
<script src="https://maxcdn.bootstrapcdn.com/bootstrap/3.3.7/js/bootstrap.min.js"
integrity="sha384-Tc5IQib027qvyjSMfHjOMaLkfuWVxZxUPnCJA7l2mCWNIpG9mGCD8wGNIcPD7Txa"
crossorigin="anonymous"></script>
Martijn
[1] https://www.w3.org/TR/SRI/
On Fri, Jan 13, 2017 at 5:42 AM, Tobias Soloschenko
<to...@googlemail.com> wrote:
> Hi,
>
> I think that there is also a change need to be done before release - see: https://github.com/apache/wicket/pull/195#issuecomment-271501638
>
> For Wicket 8 this would require a release for open-json. Wicket 6+7 can be changed by code
>
> kind regards
>
> Tobias
>
>> Am 13.01.2017 um 00:08 schrieb Martin Grigorov <mg...@apache.org>:
>>
>> 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 <mg...@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 <pe...@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 <mg...@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 <sv...@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.delbene@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.delbene@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
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
--
Become a Wicket expert, learn from the best: http://wicketinaction.com
Re: What else do we want to do before 8.0.0 final ?
Posted by Tobias Soloschenko <to...@googlemail.com>.
Hi,
I think that there is also a change need to be done before release - see: https://github.com/apache/wicket/pull/195#issuecomment-271501638
For Wicket 8 this would require a release for open-json. Wicket 6+7 can be changed by code
kind regards
Tobias
> Am 13.01.2017 um 00:08 schrieb Martin Grigorov <mg...@apache.org>:
>
> 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 <mg...@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 <pe...@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 <mg...@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 <sv...@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.delbene@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.delbene@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
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>
>>>>
>>>
>>
>>