Re: WICKET-6514 and FeedbackPanel
On Thu, Jan 4, 2018 at 5:17 PM, Andrea Del Bene wrote: > I couldn't sleep because I've read about Meltdown and Spectre bugs :-). > All joking aside, I've added a test case for FeedbackPanel and session > messages. To restore the original behavior I've changed > FeedbackMessagesModel adding an includeSession flag which is true by > default. > > WDYT? > LGTM! Thank you! > > On 04/01/2018 01:40, Martijn Dashorst wrote: > >> GO TO SLEEP YOU FOOL! >> >> (I couldn’t sleep due to a storm rattling my solar panels on our roof so >> I have an excuse. What’s yours?) >> >> Martijn >> >> Ps HAPPY NEW YEAR! >> >> Op 4 jan. 2018 om 01:23 heeft Andrea Del Bene het >>> volgende geschreven: >>> >>> I can take care of it tomorrow. >>> >>> >>> >>> On 03/01/2018 23:22, Martijn Dashorst wrote: > On Wed, Jan 3, 2018 at 10:43 PM, Andrea Del Bene > wrote: > Hi, > > as a result of WICKET-6514 now FeedbackPanel doesn't show anymore > session > messages. I'm not sure if this was intentional, but I think > FeedbackPanel > shouldn't change its behavior. Should we modify FeedbackPanel to > restore the > original behavior? > Yes. There are countless applications depending on this type of messaging. This is a regression. Martijn >>> >
Re: WICKET-6514 and FeedbackPanel
I couldn't sleep because I've read about Meltdown and Spectre bugs :-). All joking aside, I've added a test case for FeedbackPanel and session messages. To restore the original behavior I've changed FeedbackMessagesModel adding an includeSession flag which is true by default. WDYT? On 04/01/2018 01:40, Martijn Dashorst wrote: GO TO SLEEP YOU FOOL! (I couldn’t sleep due to a storm rattling my solar panels on our roof so I have an excuse. What’s yours?) Martijn Ps HAPPY NEW YEAR! Op 4 jan. 2018 om 01:23 heeft Andrea Del Bene het volgende geschreven: I can take care of it tomorrow. On 03/01/2018 23:22, Martijn Dashorst wrote: On Wed, Jan 3, 2018 at 10:43 PM, Andrea Del Bene wrote: Hi, as a result of WICKET-6514 now FeedbackPanel doesn't show anymore session messages. I'm not sure if this was intentional, but I think FeedbackPanel shouldn't change its behavior. Should we modify FeedbackPanel to restore the original behavior? Yes. There are countless applications depending on this type of messaging. This is a regression. Martijn
Re: 8.0.0 blockers
> I am confused. We already found what we want, thank you. Sven Am 04.01.2018 um 10:57 schrieb Martin Grigorov: Hi Korbinian, Sven, I am confused. Both of you say that jQuery is not a problem and few sentences later say that jQuery prevents the usage of defer/async... I am sure you will find your ways to do what you want! Martin On Thu, Jan 4, 2018 at 11:06 AM, Korbinian Bachl < korbinian.ba...@whiskyworld.de> wrote: Hi Martin, i think we dont see jQuery as problem, but mere the current integration of all wicket JS and ajax and the depending on it. Its more an adaption to current standards, where old IEs and other quirks in browsers aren't needed anymore - so to say. Currently wicket has a real big problem with first page impression and high speed rendering on mobile devices as all JS resources are limited by wicket in not beeing able to get deffered or even async'd. Ideally the wicket JS integration not only should accept defer but be built around full async into the JS part - that however would not be possible with jQuery as this one only allows defer at max as the ordering matters here... Best, KB - Ursprüngliche Mail - Von: "Martin Grigorov" An: dev@wicket.apache.org Gesendet: Dienstag, 2. Januar 2018 12:43:41 Betreff: Re: 8.0.0 blockers Hi, 1) one can always replace the version with JavaScriptLibrarySettings 2.x is used as default because most jQuery plugins are not migrated to 3.x, JS folks moved to more modern JS solutions (React, Angular, Vue, ...) 2) wicket-ajax-*jquery*.js is named this way because it depends on jQuery! One can always implement the Wicket.xyz JS APIs on top of vanilla JS, Dojo 2.x, Angular 5.x, ... And use it via JavaScriptLibrarySettings#setWicketAjaxReference() Such alternative implementation can be introduced at any version of Wicket. But what exactly is the problem with jQuery (in Wicket) ? Why its event listeners do not work for this use case ? Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Tue, Jan 2, 2018 at 12:54 PM, Sven Meier wrote: Please take a look at the pull request: https://github.com/apache/wicket/pull/253 As you can see, there are many places that have to work together - do you see a good way to make that configurable? I'd prefer to support a single solution only: addEventListener() instead of jQuery "domready"/"load" and maybe a central hook allowing to defer all JavaScript resources (perhaps there's already one I'm not aware of). This way users can defer JavaScript if they want to, but we don't force it on everyone (e.g. if they still need JavaScriptHeaderItems). IMHO moving the framework away from jQuery is the right direction anyway (see http://youmightnotneedjquery.com/), but perhaps Wicket 8 (or shortly before the 8.0.0 release) is not the right moment for it. Regards Sven Am 02.01.2018 um 11:34 schrieb Martin Makundi: If configuration option is final solution then yes, otherwise it opens a new can of worms for backwards (and on-site branching) compatibility. ** Martin +0.02 2018-01-02 12:29 GMT+02:00 Korbinian Bachl e>: May I ask why not a simple Config option? When disabled current behaviour (default) but when turned on new behaviour? That way it wont break anything and may be added to wicket any time? I just ask because this "not in that version" etc. usually is the reason why some Frameworks seems less active/ agile as others. Maybe I miss the big picture but I really would hate it if I have to wait for a new major version of wicket each time we need to keep up with the developement of the browsers... long time ago there was a discussion what version of jQuery should be in wicket and it went on 2, a sane idea at that time, but now as its 2018 I - for example - would instead now only ship JQuery 3.x default for wicket as the time has changed. I wonder how wicket will keep up with that if the cycle is so long each time... Best KB PS: I know that you can override the jQuery version as you like, it is just an example how the "best idea/ way to do it" changes over time - Ursprüngliche Mail - Von: "Sven Meier" An: dev@wicket.apache.org Gesendet: Dienstag, 2. Januar 2018 10:57:39 Betreff: Re: 8.0.0 blockers Hi Maxim, I don't think WICKET-6498 will be part of Wicket 8: There are still conceptual open questions (who decides what resources to defer) and implementation issues, i.e. does the proposed solution with addEventListener work in all browsers. Thanks for testing this. Sven Gesendet mit Blue Am 2. Jan. 2018, 09:13, um 09:13, Maxim Solodovnik < solomax...@gmail.com schrieb: I'll try to test WICKET-6498 today/tomorrow On Sun, Dec 31, 2017 at 5:04 PM, Martijn Dashorst < martijn.dasho...@gmail.com> wrote: I’m working on restyling the QuickStart to look like the new examples. Not a blocker but would be awesome to include. Will work on it 2nd Jan Martijn Op vr 29 dec. 2017 om 20:28 schreef Korbinian Bach
Re: 8.0.0 blockers
Hi Korbinian, Sven, I am confused. Both of you say that jQuery is not a problem and few sentences later say that jQuery prevents the usage of defer/async... I am sure you will find your ways to do what you want! Martin On Thu, Jan 4, 2018 at 11:06 AM, Korbinian Bachl < korbinian.ba...@whiskyworld.de> wrote: > Hi Martin, > > i think we dont see jQuery as problem, but mere the current integration of > all wicket JS and ajax and the depending on it. Its more an adaption to > current standards, where old IEs and other quirks in browsers aren't needed > anymore - so to say. > > Currently wicket has a real big problem with first page impression and > high speed rendering on mobile devices as all JS resources are limited by > wicket in not beeing able to get deffered or even async'd. Ideally the > wicket JS integration not only should accept defer but be built around full > async into the JS part - that however would not be possible with jQuery as > this one only allows defer at max as the ordering matters here... > > Best, > > KB > > > - Ursprüngliche Mail - > > Von: "Martin Grigorov" > > An: dev@wicket.apache.org > > Gesendet: Dienstag, 2. Januar 2018 12:43:41 > > Betreff: Re: 8.0.0 blockers > > > Hi, > > > > 1) one can always replace the version with JavaScriptLibrarySettings > > 2.x is used as default because most jQuery plugins are not migrated to > 3.x, > > JS folks moved to more modern JS solutions (React, Angular, Vue, ...) > > > > 2) wicket-ajax-*jquery*.js is named this way because it depends on > jQuery! > > One can always implement the Wicket.xyz JS APIs on top of vanilla JS, > Dojo > > 2.x, Angular 5.x, ... And use it via > > JavaScriptLibrarySettings#setWicketAjaxReference() > > Such alternative implementation can be introduced at any version of > Wicket. > > > > > > But what exactly is the problem with jQuery (in Wicket) ? > > Why its event listeners do not work for this use case ? > > > > > > Martin Grigorov > > Wicket Training and Consulting > > https://twitter.com/mtgrigorov > > > > On Tue, Jan 2, 2018 at 12:54 PM, Sven Meier wrote: > > > >> Please take a look at the pull request: > >> > >> https://github.com/apache/wicket/pull/253 > >> > >> As you can see, there are many places that have to work together - do > you > >> see a good way to make that configurable? > >> > >> I'd prefer to support a single solution only: > >> addEventListener() instead of jQuery "domready"/"load" and maybe a > central > >> hook allowing to defer all JavaScript resources (perhaps there's already > >> one I'm not aware of). > >> > >> This way users can defer JavaScript if they want to, but we don't force > it > >> on everyone (e.g. if they still need JavaScriptHeaderItems). > >> IMHO moving the framework away from jQuery is the right direction anyway > >> (see http://youmightnotneedjquery.com/), but perhaps Wicket 8 (or > shortly > >> before the 8.0.0 release) is not the right moment for it. > >> > >> Regards > >> Sven > >> > >> > >> > >> Am 02.01.2018 um 11:34 schrieb Martin Makundi: > >> > >>> If configuration option is final solution then yes, otherwise it opens > a > >>> new can of worms for backwards (and on-site branching) compatibility. > >>> > >>> ** > >>> Martin > >>> +0.02 > >>> > >>> 2018-01-02 12:29 GMT+02:00 Korbinian Bachl > >>> e>: > >>> > >>> May I ask why not a simple Config option? When disabled current > behaviour > (default) but when turned on new behaviour? That way it wont break > anything > and may be added to wicket any time? > > I just ask because this "not in that version" etc. usually is the > reason > why some Frameworks seems less active/ agile as others. Maybe I miss > the > big picture but I really would hate it if I have to wait for a new > major > version of wicket each time we need to keep up with the developement > of > the > browsers... long time ago there was a discussion what version of > jQuery > should be in wicket and it went on 2, a sane idea at that time, but > now > as > its 2018 I - for example - would instead now only ship JQuery 3.x > default > for wicket as the time has changed. > I wonder how wicket will keep up with that if the cycle is so long > each > time... > > Best > > KB > > PS: I know that you can override the jQuery version as you like, it is > just an example how the "best idea/ way to do it" changes over time > > - Ursprüngliche Mail - > > > Von: "Sven Meier" > > An: dev@wicket.apache.org > > Gesendet: Dienstag, 2. Januar 2018 10:57:39 > > Betreff: Re: 8.0.0 blockers > > Hi Maxim, > > > > I don't think WICKET-6498 will be part of Wicket 8: > > There are still conceptual open questions (who decides what > resources to > > > defer) > > > and implementation issues, i.e. does the proposed solution with > > addEventListener work in all browsers. > > > >
Re: WICKET-6514 and FeedbackPanel
Hi, https://git-wip-us.apache.org/repos/asf?p=wicket.git;a=commitdiff;h=63a3296;hp=db2317bf4c08074277294dbe596af841639513de Here I have preserved the old behavior in FencedFeedbackPanel and BaseWicketTester. No other tests (in Wicket) failed so I thought there is nothing else to touch. Please add a new test case or move the one from WicketStuff. Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Wed, Jan 3, 2018 at 11:43 PM, Andrea Del Bene wrote: > Hi, > > as a result of WICKET-6514 now FeedbackPanel doesn't show anymore session > messages. I'm not sure if this was intentional, but I think FeedbackPanel > shouldn't change its behavior. Should we modify FeedbackPanel to restore > the original behavior? > > PS: I've noted this change with FeedbackPanel because now a wicketstuff > test fails (org.wicketstuff.minis.component.DefaultInvisibleFeedbackPan > elTest.testVisibility). > > Andrea. > >
Re: 8.0.0 blockers
Hi Martin, i think we dont see jQuery as problem, but mere the current integration of all wicket JS and ajax and the depending on it. Its more an adaption to current standards, where old IEs and other quirks in browsers aren't needed anymore - so to say. Currently wicket has a real big problem with first page impression and high speed rendering on mobile devices as all JS resources are limited by wicket in not beeing able to get deffered or even async'd. Ideally the wicket JS integration not only should accept defer but be built around full async into the JS part - that however would not be possible with jQuery as this one only allows defer at max as the ordering matters here... Best, KB - Ursprüngliche Mail - > Von: "Martin Grigorov" > An: dev@wicket.apache.org > Gesendet: Dienstag, 2. Januar 2018 12:43:41 > Betreff: Re: 8.0.0 blockers > Hi, > > 1) one can always replace the version with JavaScriptLibrarySettings > 2.x is used as default because most jQuery plugins are not migrated to 3.x, > JS folks moved to more modern JS solutions (React, Angular, Vue, ...) > > 2) wicket-ajax-*jquery*.js is named this way because it depends on jQuery! > One can always implement the Wicket.xyz JS APIs on top of vanilla JS, Dojo > 2.x, Angular 5.x, ... And use it via > JavaScriptLibrarySettings#setWicketAjaxReference() > Such alternative implementation can be introduced at any version of Wicket. > > > But what exactly is the problem with jQuery (in Wicket) ? > Why its event listeners do not work for this use case ? > > > Martin Grigorov > Wicket Training and Consulting > https://twitter.com/mtgrigorov > > On Tue, Jan 2, 2018 at 12:54 PM, Sven Meier wrote: > >> Please take a look at the pull request: >> >> https://github.com/apache/wicket/pull/253 >> >> As you can see, there are many places that have to work together - do you >> see a good way to make that configurable? >> >> I'd prefer to support a single solution only: >> addEventListener() instead of jQuery "domready"/"load" and maybe a central >> hook allowing to defer all JavaScript resources (perhaps there's already >> one I'm not aware of). >> >> This way users can defer JavaScript if they want to, but we don't force it >> on everyone (e.g. if they still need JavaScriptHeaderItems). >> IMHO moving the framework away from jQuery is the right direction anyway >> (see http://youmightnotneedjquery.com/), but perhaps Wicket 8 (or shortly >> before the 8.0.0 release) is not the right moment for it. >> >> Regards >> Sven >> >> >> >> Am 02.01.2018 um 11:34 schrieb Martin Makundi: >> >>> If configuration option is final solution then yes, otherwise it opens a >>> new can of worms for backwards (and on-site branching) compatibility. >>> >>> ** >>> Martin >>> +0.02 >>> >>> 2018-01-02 12:29 GMT+02:00 Korbinian Bachl >> e>: >>> >>> May I ask why not a simple Config option? When disabled current behaviour (default) but when turned on new behaviour? That way it wont break anything and may be added to wicket any time? I just ask because this "not in that version" etc. usually is the reason why some Frameworks seems less active/ agile as others. Maybe I miss the big picture but I really would hate it if I have to wait for a new major version of wicket each time we need to keep up with the developement of the browsers... long time ago there was a discussion what version of jQuery should be in wicket and it went on 2, a sane idea at that time, but now as its 2018 I - for example - would instead now only ship JQuery 3.x default for wicket as the time has changed. I wonder how wicket will keep up with that if the cycle is so long each time... Best KB PS: I know that you can override the jQuery version as you like, it is just an example how the "best idea/ way to do it" changes over time - Ursprüngliche Mail - > Von: "Sven Meier" > An: dev@wicket.apache.org > Gesendet: Dienstag, 2. Januar 2018 10:57:39 > Betreff: Re: 8.0.0 blockers > Hi Maxim, > > I don't think WICKET-6498 will be part of Wicket 8: > There are still conceptual open questions (who decides what resources to > defer) > and implementation issues, i.e. does the proposed solution with > addEventListener work in all browsers. > > Thanks for testing this. > Sven > > Gesendet mit Blue > > Am 2. Jan. 2018, 09:13, um 09:13, Maxim Solodovnik < > solomax...@gmail.com > > schrieb: > >> I'll try to test WICKET-6498 today/tomorrow >> >> On Sun, Dec 31, 2017 at 5:04 PM, Martijn Dashorst < >> martijn.dasho...@gmail.com> wrote: >> >> I’m working on restyling the QuickStart to look like the new >>> >> examples. Not >> >>> a blocker but would be awesome to include. Will work on it 2nd Jan >>> >>> Martijn >>> >>>
Re: WICKET-6514 and FeedbackPanel
Op do 4 jan. 2018 om 03:42 schreef Maxim Solodovnik > I thought this API break was "by design" > Maybe this can be documented instead? > FeedbackPanel should use the constructor with session messages enabled. That is the API break, not the collector change. Martijn > WBR, Maxim > (from mobile, sorry for the typos) > > On Thu, Jan 4, 2018, 05:22 Martijn Dashorst > wrote: > > > On Wed, Jan 3, 2018 at 10:43 PM, Andrea Del Bene > > wrote: > > > Hi, > > > > > > as a result of WICKET-6514 now FeedbackPanel doesn't show anymore > session > > > messages. I'm not sure if this was intentional, but I think > > FeedbackPanel > > > shouldn't change its behavior. Should we modify FeedbackPanel to > restore > > the > > > original behavior? > > > > Yes. There are countless applications depending on this type of > > messaging. This is a regression. > > > > Martijn > > > -- Become a Wicket expert, learn from the best: http://wicketinaction.com
Re: 8.0.0 blockers
Hi, I don't see a problem with jQuery in Wicket, I see room for improvements. It's how we use jQuery that prevents users from using deferred JavaScript resources. As I have written I don't see this as urgent as Korbinian sees it - for me this is not a 8.0.0 blocker! But for frameworks its important IMHO to adapt to latests technologies (i.e. defer) and community interests (e.g. first page impression). I don't want to tell users to implement their own Wicket.xyz JS just to use newest technologies. I'll try to flesh out my proposal after we got out 8.0.0. Sven Am 02.01.2018 um 12:43 schrieb Martin Grigorov: Hi, 1) one can always replace the version with JavaScriptLibrarySettings 2.x is used as default because most jQuery plugins are not migrated to 3.x, JS folks moved to more modern JS solutions (React, Angular, Vue, ...) 2) wicket-ajax-*jquery*.js is named this way because it depends on jQuery! One can always implement the Wicket.xyz JS APIs on top of vanilla JS, Dojo 2.x, Angular 5.x, ... And use it via JavaScriptLibrarySettings#setWicketAjaxReference() Such alternative implementation can be introduced at any version of Wicket. But what exactly is the problem with jQuery (in Wicket) ? Why its event listeners do not work for this use case ? Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Tue, Jan 2, 2018 at 12:54 PM, Sven Meier wrote: Please take a look at the pull request: https://github.com/apache/wicket/pull/253 As you can see, there are many places that have to work together - do you see a good way to make that configurable? I'd prefer to support a single solution only: addEventListener() instead of jQuery "domready"/"load" and maybe a central hook allowing to defer all JavaScript resources (perhaps there's already one I'm not aware of). This way users can defer JavaScript if they want to, but we don't force it on everyone (e.g. if they still need JavaScriptHeaderItems). IMHO moving the framework away from jQuery is the right direction anyway (see http://youmightnotneedjquery.com/), but perhaps Wicket 8 (or shortly before the 8.0.0 release) is not the right moment for it. Regards Sven Am 02.01.2018 um 11:34 schrieb Martin Makundi: If configuration option is final solution then yes, otherwise it opens a new can of worms for backwards (and on-site branching) compatibility. ** Martin +0.02 2018-01-02 12:29 GMT+02:00 Korbinian Bachl : May I ask why not a simple Config option? When disabled current behaviour (default) but when turned on new behaviour? That way it wont break anything and may be added to wicket any time? I just ask because this "not in that version" etc. usually is the reason why some Frameworks seems less active/ agile as others. Maybe I miss the big picture but I really would hate it if I have to wait for a new major version of wicket each time we need to keep up with the developement of the browsers... long time ago there was a discussion what version of jQuery should be in wicket and it went on 2, a sane idea at that time, but now as its 2018 I - for example - would instead now only ship JQuery 3.x default for wicket as the time has changed. I wonder how wicket will keep up with that if the cycle is so long each time... Best KB PS: I know that you can override the jQuery version as you like, it is just an example how the "best idea/ way to do it" changes over time - Ursprüngliche Mail - Von: "Sven Meier" An: dev@wicket.apache.org Gesendet: Dienstag, 2. Januar 2018 10:57:39 Betreff: Re: 8.0.0 blockers Hi Maxim, I don't think WICKET-6498 will be part of Wicket 8: There are still conceptual open questions (who decides what resources to defer) and implementation issues, i.e. does the proposed solution with addEventListener work in all browsers. Thanks for testing this. Sven Gesendet mit Blue Am 2. Jan. 2018, 09:13, um 09:13, Maxim Solodovnik < solomax...@gmail.com schrieb: I'll try to test WICKET-6498 today/tomorrow On Sun, Dec 31, 2017 at 5:04 PM, Martijn Dashorst < martijn.dasho...@gmail.com> wrote: I’m working on restyling the QuickStart to look like the new examples. Not a blocker but would be awesome to include. Will work on it 2nd Jan Martijn Op vr 29 dec. 2017 om 20:28 schreef Korbinian Bachl < korbinian.ba...@whiskyworld.de> May I also mention WICKET-6498? https://issues.apache.org/jira/browse/WICKET-6498 - Ursprüngliche Mail - Von: "Sven Meier" An: dev@wicket.apache.org Gesendet: Freitag, 29. Dezember 2017 16:22:47 Betreff: Re: 8.0.0 blockers Not strictly necessary, but I would like to merge WICKET-6503: https://issues.apache.org/jira/browse/WICKET-6503 Have fun Sven Am 29.12.2017 um 06:02 schrieb Maxim Solodovnik: Hello All, Is it time for release? There are long holidays upcoming here, so I can send more time on Wicket :))) On Thu, Nov 30, 2017 at 9:36 PM, Andrea Del Bene < an.delb...@gmail.com> wrote: On Thu, Nov 30, 2017 at 1:07 PM, Mar
