On Wed, Aug 14, 2019 at 10:19 AM Sven Meier <s...@meiers.net> wrote: > Hi Korbinian, > > Wicket Ajax is primarily used for UI updates, thus all requests *have* > to be sent sequentially: Otherwise user input > (click...tab...type...click...click) would not be processed in a > deterministic way! > Furthermore all requests are queued on the server too (each page is > locked separately), so developers don't need to tackle multi-threading > in their UI code. > > I'm not aware of any UI toolkit that is multi-threaded. Because of our > use of Ajax, users can still continue to use the UI while a request is > running - that's better than other solutions (e.g. Swing or Android) > where everything is halted (layout, repaint) until the processing has > finished. > > Regarding parallel file uploads: > This is clearly something that could be done asynchronously since it > doesn't interfere with user input. > For the JS side you just have to use a separate Ajax channel. But the > request has to be targeted at a resource instead of a component, since > the former is processed in parallel. > > Take a look at AjaxDownloadBehavior, it is able to target a resource > (locks the page) or a resourceReference (doesn't lock the page). > Maybe we can improve AjaxFileDropBehaviour to do something similar. >
+1 After reading the last paragraph I think AjaxUploadBehavior would have been a better name for this class, since it is the opposite of AjaxDownloadBehavior. But naming has always have been hard! :-) > > Have fun > Sven > > > On 13.08.19 21:17, Korbinian Bachl wrote: > > Hi Sven, > > > > so to get this right: all wicket ajax is basically a queue where only 1 > instance is worked on at a time and nothing is possible in parallel? > > (but browsers and ajax in parallel is working since at least 2011? e.g.: > jQuery.when() ) > > > > You mention the upload to a resource - how would this change it in that > in could be parallel and could you point me an example? > > > > Best & Thanks for the answer so far, > > > > KB > > > > ----- Ursprüngliche Mail ----- > >> Von: "Sven Meier" <s...@meiers.net> > >> An: "users" <users@wicket.apache.org> > >> Gesendet: Dienstag, 13. August 2019 09:03:49 > >> Betreff: Re: multiple AjaxFileDropBehaviour on single page > >> Hi, > >> > >> all Ajax behaviors' requests are queued in the browser. Even if you > >> disable this (see AjaxRequestAttributes#channel), all access to the page > >> is synchronized on the server anyway. > >> > >> You could to upload to a resource instead, AjaxFileDropBehaviour doesn't > >> support this though. > >> > >> Have fun > >> Sven > >> > >> > >> On 13.08.19 08:19, Korbinian Bachl wrote: > >>> Hi, > >>> > >>> wicket 8 has this neat AjaxFileDropBehaviour and it works like charm. > However, > >>> if I have multiple components on one page with a AjaxFileDropBehaviour > each and > >>> the upload of 1 drop is running, i cant upload a 2nd one at the same > time; Any > >>> idea how to solve this? > >>> > >>> E.g.: File 1 with 100MB gets dropped onto component A, File B wiht > 50MB gets > >>> dropped onto Component B about 10 secs later - upload of a is not > working and > >>> page somehow goes stale. It might be noteworthy that during the upload > an > >>> IAjaxIndicatorAware spinner is shown on Component A (and expected on > B); > >>> > >>> Best, > >>> > >>> KB > >>> > >>> --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > >>> For additional commands, e-mail: users-h...@wicket.apache.org > >>> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > >> For additional commands, e-mail: users-h...@wicket.apache.org > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > > For additional commands, e-mail: users-h...@wicket.apache.org > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >