Yes, the poblem is that a page-requests may not be for the page itself, but for resources on the page (e.g. ImageResources attached to an Image object, in which case Image has a listener for the resource). Such requests will still block ajax requests from that page. Something you definitely do not want. Since there are many possible usecases in which the browser can make requests for these resources, and at the same time ajax requests. I can understand that in most cases you want the page request to block the ajax request, but in the case as desribed above, that will be a problem. I guess the solution would be to relax the checks, based on either the version of the page (which would solve your specific usecase described in your email, but maybe not all possible usecases), or on what is exactly requested (i.e. requests to component listeners do not block ajax requests). But this may need some more discussion and more usecases that involve both normal requests on ajax requests.
On Thu, 18 Sep 2008 16:22:09 +0200, "Matej Knopp" <[EMAIL PROTECTED]> said: > I have never seen any problems with the check. > The reason is that some browsers fire the ajax request even after user > has > already clicked another link on page (normal page request). That can have > negative impact on the server side state. e.g. > > user is on page 1 version 1 > clicks an ajax link and immediately also regular link > the regular link increments page version, browser starts loading page 1 > version 2 > unfortunately on certain browsers the xmlhttprequest from ajax link is > not > killed, so after the page is loaded, server gets the original ajax > reuqest > which leads to reverting page state > > this can also cause problem when the ajax request doesn't revert page > state > but r.g. removes component. for the new request nothing can update client > side (because the request is not fired from the newly loaded page). > > so the check is to prevent such ajax request. as i understand the problem > it > causes is when there is regular request to page that doesn't reload the > page > - the ajax request is still thrown away. > > -Matej > > On Thu, Sep 18, 2008 at 9:52 AM, Pointbreak > <[EMAIL PROTECTED]<[EMAIL PROTECTED]> > > wrote: > > > The WebRequestCyclyProcessor substitutes without warnings or error > > messages ajax requests, when wicket is at the same time processing page > > requests for that page. This may break applications that serve > > non-shared resources such as images (which will also trigger erquests to > > the page), and do ajax requests from the same page. Afaik, as a > > programmer you have no control over when the browser actually makes > > requests for the images on the page, and how long these requests take. > > But during such requests all ajax processing of the page is silently > > ignored. > > > > Can somebody shed some light on why this is actually implemented this > > way, and if I am correct considering this is a bug? > >
