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