Hi,
On Tue, May 20, 2025 at 2:36 AM Johan Stuyts <johanstu...@squins.com> wrote: > Hi, > > Our infrastructure seems to be blocking some Ajax requests sporadically. > So we end up with the situation where the state in the session no longer > matches the components shown on the screen. > > I already took some measures to prevent exceptions, but the user > experience is still lousy. Here is what happens: > > 1. Ajax: user checks a checkbox. Components become visible. > 2. Ajax: user sets a radio button. More components become visible. > 3. Ajax: user unchecks the checkbox. THIS REQUEST IS BLOCKED. > 4. User submits the form. Errors appear for the components from step 2 > because they are required. This is confusing for the user as the checkbox > is not checked, so the components are no longer relevant. > We are using what Martin suggested. We have a global listener that detects those errors and tells the user things went wrong. After we activated this we discovered a few places in our application where we were "swaloging" failed requests. > Are there techniques to handle situations like this? I thought of an Ajax > timer to synchronize the server and client state, but chances are these > requests will also be blocked (and it would increase the load on the > system). > The real problem for me is to find out why those requests fail and fix infrastructure. If this happens always in the same place. You could: - Have a hidden refresh UI button (this could be added for instance as an AJAX behavior to be added to some panels. This button will trigger a normal AJAX repaint (not a post) - Combine the previous point with the listener... Then the request fails => 1) you show some notification telling the user request failed 2) make the button visible. Another variation would be if the request fails you don't tell the user but click on this hidden refresh button. - I would also only enable the submit button once the UI is correct. > > Thanks in advance for your answers. > > -- > Best regards, > > Johan Stuyts > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > -- Regards - Ernesto Reinaldo Barreiro
