Cancel filter editor server requests?

[pkelley]

We have a ListGrid with a FilterEditor. One of the columns is a SelectItem that allows selecting multiple values and is tied to an Optionsdatasource for its values.

The filtering is setup to be automaticially applied (instead of waiting for the user to set everything and then click the button to filter)

The issue is that we are seeing that if you select a few items in the SelectItem, one at a time, you can visibly see the results for only the first item in the table, then a small delay, and then the results for the first two clicks, then another deltay, and so on.

Is there a way to cancel any previous filter requests sent to the server when a new filter option is desired. In other words, when the second item is selected in the SelectItem is there a way to cancel the filter request for the selection of the first item before submitting the new filter request?

Thank you in advance.
Patrick

[Isomorphic]

There's no way to really cancel the *server-side work* of a request that has already left the browser. The best you could do would be to launch a second request and use server-side cross-thread communication (very complex) to try to interrupt the first request, which would be very unlikely to have a net performance benefit.

It's not clear what's causing the delay you're seeing - actually it's not quite clear what the delay visually looks like. Can you use something like Jing to get a recording of what you're seeing?

[pkelley]

We will work on getting a video capture. Can you email us a method of sending it to you directly without posting to this forum?

To add a little more information, you can picture clicking 3 boxes in a row in a multi-select enabled SelectItem. Then imagine seeing the results of the filtering with just the first option click appearing, followed soon by the results of the second item also being clicked and finally seeing the desired results of all 3 options.

While it is not a huge delay it is certainly noticeable and given the Ajax type nature of these applications the user won't know if they have all the results or not.

This is why we were wondering if there was a way to tell the client to only update with the results coming back from the server for the most recent request and not bother with any returns from earlier (now stale) requests.... or if you had seen and solved this using some other approach.

[Isomorphic]

If you create a video capture, email it to support@isomorphic.com.

We cannot tell from your description what the delay actually looks like or what is happening during the delay - an empty message? A comm delay or something else?

Either a video or a clearer prose description would help. You can also look into what the delay actually is by examining timestamps in the RPC tab of the Developer Console.

[pkelley]

Here is a more clear description:

With a table full of data expand the multi-select SelectItem in the FilterEditor. Quickly select 4 items in a the SelectItem.

The initial set of data arrives and fills the table. This is the original table data filtered to include only the first option that was selected in the SelectItem.

Then the data in the table grows, after a small delay, which is the table data filtered to include the first and second options selected in the SelectItem. There is no transition. It goes from the first set of data in the table to this new larger dataset. It looks like the table just suddenly doubled in size with no prompting from the user.

The process is then repeated for the 3rd and any additional options selected in the SelectItem, each time with a small delay.

Our desired behavior is for each click in the SelectItem to do something to cancel (client side is fine) the updating of the table for each of the previous clicks since those requests are now stale. We would like to wait and only show the desired dataset which is the original dataset filtered to include all of the SelectItem selections. We were wondering if you had any suggestions to accomplish this.

[Isomorphic]

That's clearer, but unfortunately doesn't address the main question..

The grid can't show data any sooner than the server returns it. Do you have reason to believe that there is any significant delay between when the server returns the last matching dataset and when it is displayed? If not, there's no way to speed up the client, you need to speed up the server.

[pkelley]

Ok, that does help. We are not doing anything that should slow down showing the results.

1) There may be lag in our lab setup right now, but beyond speeding that up, can you point us to any suggestions or things to look at to speed up the server?

2) Since there is always a chance for lag, is there any way to implement our idea, to tell the client to only update with the most recent request and to ignore any other returns from the server? Or something similar that would have the same effect.

[Isomorphic]

1) We can't really respond to this except by providing a treatise on server performance optimization :) Can you ask something more specific, or take a crack at looking at driving factors in performance first by at least identifying network time vs database time vs other time - just a very high-level breakdown.

2) We wouldn't really recommend going down this path. This wouldn't speed up the final result if the bottleneck is the server, and if the server is responding more quickly, would probably be a worse UI. It also introduces a bunch of complexity and ambiguity around whether callbacks or events should fire if data has arrived but is not being displayed. For example: should DataArrived fire? If it does, what state should the data be in?