On Fri, Jul 27, 2012 at 2:38 PM, Emond Papegaaij <[email protected]> wrote: > On Friday 27 July 2012 13:00:33 Martijn Dashorst wrote: >> On Fri, Jul 27, 2012 at 12:04 PM, Martin Grigorov <[email protected]> > wrote: >> > I've made some bigger changes in wicket-ajax.js lately. Mostly because >> > of requests/tickets by Christian Oldiges. He is not subscribed to the >> > mailing lists but he suggested in IRC to do beta4 because of this. >> > My personal opinion is that the changes are stable enough for >> > 6.0.0.final. The unit tests prove it. If there are more bugs we will >> > fix them in 6.0.1. >> >> I'll roll 6.0 final, and let Emond do the testing work for this :-) > > With the additions I did a few days ago to wicket-ajax, I'd go for final. IMHO > we should only create a beta if we know it is broken. > >> > Christian created also >> > https://issues.apache.org/jira/browse/WICKET-4675 which requires quite >> > a big change in both JS and Java code. Honestly I'm afraid of such >> > changes, especially just before 6.0.0.final. If someone has a simpler >> > solution for the described problem then please share it now, otherwise >> > I suggest to leave this ticket for some future version. >> >> It looks like an API addition, so that can go in 6.1 (unfortunately, >> AjaxRequestTarget is now an interface, so it might have to wait until >> 7) > > We do you need changes to the Java code for this? Isn't enough to ensure that > the processing of an AJAX response is executed atomically, which should also > not be a big problem, given the fact that javascript is single threaded.
Single threaded as far as you don't use setTimeout. Until recently there was such a use in the steps (FunctionExecuter) which made the processing kinda random. I removed this in 6.0-SNAPSHOT. But you are right that now all should be fine. I'll discuss with Christian again how exactly he faced the problem. > > Best regards, > Emond -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com
