ComboBoxItem vs. Record Paging

[yavery]

Hi,

I experienced a problem with a ComboBoxItem bound to a datasource that uses paging.

Since it would be really hard to provide a test-bed, here are the detailed steps to reproduce the problem.

1. Open the ComboBoxItem so the 1st page gets requested and displayed (paging requests range 0-75)
2. While the ComboBoxItem is opened, scroll down to the bottom of the list so the last page gets requested (paging requests range 81-127)
3. In the text field, type something that will filter the list you're currently looking at. Such a filter will send a request to the server with a paging request that has an invalid range (in my case, the range sent is 85-159).

In this case, the server returns a 416 HTTP status code ("Requested Range Not Satisfiable").

The work-around I found for this situation is to override 2 methods:

            refreshPickList : function()
            {
                // reset data scrolling to avoid potential 'HTTP 416 request range not satisfiable'
                if (!this.optionFilterContext)
                    this.optionFilterContext = {};
                this.optionFilterContext['startRow'] = 0;

                // let base class do its thing
                return this.Super('refreshPickList', arguments);
            },
            resetField: function() {
                this.clearValue();
                this.optionFilterContext = { startRow : 0 }; // reset data scrolling to avoid potential 'HTTP 416 request range not satisfiable'
            }

Specifying "startRow" fixed the issue, but the problem is that now that I defined "startRow" in one call, we do not get the paging/range benefit anymore since all the requests going to the server explicitly set "startRow" to 0.

In the ListGrid, when a 416 code is received from the server, the list automatically fires a new request with a 0-75 paging/range request as a fallback mechanism.

Is there a reason why ComboBoxIetm and ListGrid do not behave the same ?

Did I miss something ?

Thank you !

[Isomorphic]

The expectation is that the server does something reasonable in this case rather than flinging back an error message and no data. After all, the client *should* try to preserve scroll position by asking for the same row range it's displaying and the client has no way of verifying that it's row range is going to be valid.

For this reason the SmartClient Server returns the nearest matching range for such a request, and the best solution is to fix your server to do this too; you may be able to install a FilterServlet or similar to catch 416 responses and programmatically issue a series of requests to get the data the client needs.

Let us know if this is, for whatever reason, impossible; if so we can provide a supportable way to do this client-side that won't involve hacks.

[yavery]

Hi,

I understand what you're saying, but why does this work properly for listGrid components but not for combobox items ?

I would have expected the same behaviour from both components ...

Any idea, what we could change in our combo box implementation to have that same behaviour ?

Thanks,

[Isomorphic]

We didn't design specific handling for this scenario because we regard it as just broken server behavior that should be corrected server-side. So, not sure why the ListGrid vs ComboBoxItem handling happens to be different here, but it's not something we'd try to keep consistent in the future, so there would be little point in a hack that would make it consistent now.

Do you want to pursue a client-side approach for handling this cleanly (it would be based on DataSource.clientCustom) or do you have a way of handling it server-side?

[yavery]

Hi,

To keep you guys updated ... We are currently looking at changing our backend, but at this
point we don't yet know if that's the direction we'll take or not.

I'll keep you updated if I require a client-side solution to this problem.

Thanks,