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
>
>

Reply via email to