add some flag that allows to block users selecting an option while a …

[ernestosemedy]

add some flag that allows to block users selecting an option while a query is in process

@sebfz1 this PR is based on some changes I did for our project. We will soon test this in our pre-production environment and see if that fixes the issue we are experiencing there. The issue being:

1. Users select something at client side
2. Wrong selection is done in server because user selected sate data in client and a request was sent to server side that didn't return items yet.

This PR tries to prevent the user from being able to select something while there is a request to server. I have added this via a flag set to false so that previous behavior is set to be default

[ernestosemedy]

I see that the new logic mixes Wicket Ajax calls (Wicket.Ajax.ajax(...)) and jQuery ones ($.ajax(...)). Was this the case until now ?

Yes. See explanation bellow.

If the logic uses only Wicket Ajax JS APIs then I'd recommend trying to implement the same logic with AjaxChannel.ACTIVE. I.e. use the same channel name of select and fetch calls and they will be auto-cancelled if there is an actively running XHR request in this channel.

We have 2 operations here:

1- Fetching the data to show in drop down. By default we are passing the URL of behavior that creates the JSON data then

https://github.com/jquery/jquery-ui/blob/main/ui/widgets/autocomplete.js#L381

This is done above in

and this does not uses wicket AJAX. Thus I juts followed the same approach

2- The part doing the selection of element. This is done using wicket AJAX generated by Java code. I just translated this into low level JS.

[martin-g]

If there are both Wicket Ajax and jQuery.ajax() calls then I guess your approach is better!

[mdbergmann]

I see that the new logic mixes Wicket Ajax calls (Wicket.Ajax.ajax(...)) and jQuery ones ($.ajax(...)). Was this the case until now ?

If the logic uses only Wicket Ajax JS APIs then I'd recommend trying to implement the same logic with AjaxChannel.ACTIVE. I.e. use the same channel name of select and fetch calls and they will be auto-cancelled if there is an actively running XHR request in this channel.

Wondering if this is responsible for the Ajax related issues we've seen since Wicket 9 in wicket-jquery-ui (or Kendo actually).

[ernestosemedy]

I see that the new logic mixes Wicket Ajax calls (Wicket.Ajax.ajax(...)) and jQuery ones ($.ajax(...)). Was this the case until now ? If the logic uses only Wicket Ajax JS APIs then I'd recommend trying to implement the same logic with AjaxChannel.ACTIVE. I.e. use the same channel name of select and fetch calls and they will be auto-cancelled if there is an actively running XHR request in this channel.

Wondering if this is responsible for the Ajax related issues we've seen since Wicket 9 in wicket-jquery-ui (or Kendo actually).

Can you describe them...?

[mdbergmann]

I see that the new logic mixes Wicket Ajax calls (Wicket.Ajax.ajax(...)) and jQuery ones ($.ajax(...)). Was this the case until now ? If the logic uses only Wicket Ajax JS APIs then I'd recommend trying to implement the same logic with AjaxChannel.ACTIVE. I.e. use the same channel name of select and fetch calls and they will be auto-cancelled if there is an actively running XHR request in this channel.

Wondering if this is responsible for the Ajax related issues we've seen since Wicket 9 in wicket-jquery-ui (or Kendo actually).

Can you describe them...?

I.e. this: #333

[ernestosemedy]

If there are both Wicket Ajax and jQuery.ajax() calls then I guess your approach is better!

Yes. See explanation I gave above. So far component used:

1- JQuey Ajax to fetch data (non blocking): as we were passing URL of behavior producing JSON 2- Wicket AJAX to transfer client side selection to server side.

We will soon deploy some version of the above into our internal "production" environment were people can consistently reproduce the issue thus we will have confirmation if this code improves the situation

[ernestosemedy]

I see that the new logic mixes Wicket Ajax calls (Wicket.Ajax.ajax(...)) and jQuery ones ($.ajax(...)). Was this the case until now ? If the logic uses only Wicket Ajax JS APIs then I'd recommend trying to implement the same logic with AjaxChannel.ACTIVE. I.e. use the same channel name of select and fetch calls and they will be auto-cancelled if there is an actively running XHR request in this channel.

Wondering if this is responsible for the Ajax related issues we've seen since Wicket 9 in wicket-jquery-ui (or Kendo actually).

Can you describe them...?

I.e. this: #333

I do not see an immediate connection but I don't know what the other issue is about. If I have some time I might try to look at it but we are not using Kendo UI and I have 0 experience with that part of the code base

[mdbergmann]

I see that the new logic mixes Wicket Ajax calls (Wicket.Ajax.ajax(...)) and jQuery ones ($.ajax(...)). Was this the case until now ? If the logic uses only Wicket Ajax JS APIs then I'd recommend trying to implement the same logic with AjaxChannel.ACTIVE. I.e. use the same channel name of select and fetch calls and they will be auto-cancelled if there is an actively running XHR request in this channel.

Wondering if this is responsible for the Ajax related issues we've seen since Wicket 9 in wicket-jquery-ui (or Kendo actually).

Can you describe them...?

I.e. this: #333

I do not see an immediate connection but I don't know what the other issue is about. If I have some time I might try to look at it but we are not using Kendo UI and I have 0 experience with that part of the code base

Maybe it's completely unrelated. I dunno. Then please forget my interruption.