I've created https://issues.apache.org/jira/browse/WICKET-5267 and attached my demo app. I see no big gains with JS event delegation. Only the actually binding of all JS events is slightly faster. But clicking on the links is not faster/slower.
On Fri, Jul 5, 2013 at 3:45 PM, Martin Grigorov <mgrigo...@apache.org>wrote: > No, at the moment. > But I'll create a bigger demo application and will profile it with Google > Chrome's dev tools. > > > > On Fri, Jul 5, 2013 at 3:40 PM, Sven Meier <s...@meiers.net> wrote: > >> Do you have an actual performance comparison between multiple ajax event >> handlers and EventDelegatingBehavior? >> >> Sven >> >> >> On 07/05/2013 02:31 PM, Martin Grigorov wrote: >> >>> On Fri, Jul 5, 2013 at 3:28 PM, Sven Meier <s...@meiers.net> wrote: >>> >>> There are few (identified) problems though: >>>>> 1) if a child component is bound to an <a> element then it will fire >>>>> >>>> non-Ajax request >>>> >>>>> (because there is no JS binding that would usually prevent the default >>>>> >>>> behavior). >>>> >>>> Preventing the default should still work: >>>> >>>> http://www.bennadel.com/blog/****1611-Preventing-Default-**<http://www.bennadel.com/blog/**1611-Preventing-Default-**> >>>> Actions-In-A-Bubbled-Event-In-****jQuery.htm<http://www.** >>>> bennadel.com/blog/1611-**Preventing-Default-Actions-In-** >>>> A-Bubbled-Event-In-jQuery.htm<http://www.bennadel.com/blog/1611-Preventing-Default-Actions-In-A-Bubbled-Event-In-jQuery.htm> >>>> > >>>> >>> >>> Thanks! >>> >>> >>> >>>> Sven >>>> >>>> >>>> ------------------------------****----------------------------** >>>> --**--------- >>>> To unsubscribe, e-mail: >>>> users-unsubscribe@wicket.**apa**che.org<http://apache.org> >>>> <users-unsubscribe@**wicket.apache.org<users-unsubscr...@wicket.apache.org> >>>> > >>>> >>>> For additional commands, e-mail: users-h...@wicket.apache.org >>>> >>>> >>>> >> >> ------------------------------**------------------------------**--------- >> To unsubscribe, e-mail: >> users-unsubscribe@wicket.**apache.org<users-unsubscr...@wicket.apache.org> >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> >