I'm using SmartGWT 2.3 and GWT 2.0.4 and Firefox 3.6.
I have a ListGrid backed by a DataSource, which fetches records from the server via GWT-RPC. The data page size on the grid is set to 50. The layout containing the grid has a form where the user can enter various filters. When the user updates a filter, I create a corresponding Criteria then do:
listGrid.setCriteria(criteria)
listGrid.invalidateCache();
listGrid.fetchData(criteria);
I run into issues with this if the user scrolls to the bottom of the full unfiltered grid before updating a filter. In this case, prior to updating the filter, assuming the total data set size is 1000, the startRow and endRow are set to 950 and 1000 respectively. I would expect that both updating the criteria on the grid and invalidating the cache would cause the grid to ask for startRow=0, endRow=50 the next time fetchData() is called, but this is not what's happening. Instead, when fetchData() is called, the DSRequest that the grid passes to it's DataSource's transformRequest() method still is set to startRow=950, endRow=1000. With the criteria applied, the total data set size of the results will usually be smaller, e.g. 10, rather than 1000, making the startRow and endRow invalid and causing the server to throw an exception. Why does updating the grid's criteria or invalidating its cache not cause it to reset paging on the next fetch request? It seems like this would always be the desired behavior, particularly when updating criteria, since that's usually going to change the total data set size.
I have tried to workaround this issue in several ways:
1) call listGrid.scrollToRow(0) right after calling listGrid.setCriteria(criteria). this doesn't work. the DSReqeust still asks for rows 951-1000.
2) create a requestProperties object as follows:
DSRequest requestProperties = new DSRequest();
requestProperties.setStartRow(0);
requestProperties.setEndRow(50);
and pass that in to listGrid.fetchData(). this does result in the correct rows being fetched. however, it causes those same rows to be fetched for any future calls to fetchData(), even ones where no requestProperties are passed in.
3) in the DataSource's transformRequest() impl, do the following:
if (!CriteriaUtility.equals(request.getCriteria(), this.previousCriteria)) {
// The criteria has changed since the last fetch request - reset paging.
Log.debug("Resetting paging on " + getClass().getName() + "...");
request.setStartRow(0);
request.setEndRow(50);
}
this.previousCriteria = request.getCriteria();
This actually works, with one issue - the grid is still scrolled all the way to the bottom, since it doesn't realize the startRow and endRow were changed. I would think it would see that the totalRows on the DSResponse returned by the Datasource changed from 1000 to e.g. 10 and scroll up to the top automatically, but this doesn't happen. I tried two approaches to get it to scroll back to the top:
a) in a callback passed to fetchData(), call listGrid.scrollToRow(0). this doesn't appear to do anything. the grid remains scrolled all the way to the bottom.
b) in the DataSource, set startRow and endRow on the DSResponse to 0 and 50 to inform the ListGrid it's getting back a different set of rows than what it asked for. this results in the grid making a 2nd redundant call to transformRequest(), again passing in 951 and 1000 as the startRow and endRow. On this 2nd call, this.previousCriteria is equal to the passed in criteria (since it was already updated on the 1st call), my code for resetting paging will not execute, and the invalid startRow and endRow are passed to the server, bringing me back to the original issue.
So I am currently living with the fact that the user must scroll up to the top of the grid in order to see the filtered results.
What am I missing here? Is this a bug that's been fixed in a later release of SmartGWT? Is there a better way to make this work than my current hack in transformRequest()? I just want to reset the paging when criteria changes, make a single fetch request, and display the filtered results with the grid scrolled to row 0.
By the way, I have searched this forum and have found several similar posts, but none seemed to describe my exact use case.
I have a ListGrid backed by a DataSource, which fetches records from the server via GWT-RPC. The data page size on the grid is set to 50. The layout containing the grid has a form where the user can enter various filters. When the user updates a filter, I create a corresponding Criteria then do:
listGrid.setCriteria(criteria)
listGrid.invalidateCache();
listGrid.fetchData(criteria);
I run into issues with this if the user scrolls to the bottom of the full unfiltered grid before updating a filter. In this case, prior to updating the filter, assuming the total data set size is 1000, the startRow and endRow are set to 950 and 1000 respectively. I would expect that both updating the criteria on the grid and invalidating the cache would cause the grid to ask for startRow=0, endRow=50 the next time fetchData() is called, but this is not what's happening. Instead, when fetchData() is called, the DSRequest that the grid passes to it's DataSource's transformRequest() method still is set to startRow=950, endRow=1000. With the criteria applied, the total data set size of the results will usually be smaller, e.g. 10, rather than 1000, making the startRow and endRow invalid and causing the server to throw an exception. Why does updating the grid's criteria or invalidating its cache not cause it to reset paging on the next fetch request? It seems like this would always be the desired behavior, particularly when updating criteria, since that's usually going to change the total data set size.
I have tried to workaround this issue in several ways:
1) call listGrid.scrollToRow(0) right after calling listGrid.setCriteria(criteria). this doesn't work. the DSReqeust still asks for rows 951-1000.
2) create a requestProperties object as follows:
DSRequest requestProperties = new DSRequest();
requestProperties.setStartRow(0);
requestProperties.setEndRow(50);
and pass that in to listGrid.fetchData(). this does result in the correct rows being fetched. however, it causes those same rows to be fetched for any future calls to fetchData(), even ones where no requestProperties are passed in.
3) in the DataSource's transformRequest() impl, do the following:
if (!CriteriaUtility.equals(request.getCriteria(), this.previousCriteria)) {
// The criteria has changed since the last fetch request - reset paging.
Log.debug("Resetting paging on " + getClass().getName() + "...");
request.setStartRow(0);
request.setEndRow(50);
}
this.previousCriteria = request.getCriteria();
This actually works, with one issue - the grid is still scrolled all the way to the bottom, since it doesn't realize the startRow and endRow were changed. I would think it would see that the totalRows on the DSResponse returned by the Datasource changed from 1000 to e.g. 10 and scroll up to the top automatically, but this doesn't happen. I tried two approaches to get it to scroll back to the top:
a) in a callback passed to fetchData(), call listGrid.scrollToRow(0). this doesn't appear to do anything. the grid remains scrolled all the way to the bottom.
b) in the DataSource, set startRow and endRow on the DSResponse to 0 and 50 to inform the ListGrid it's getting back a different set of rows than what it asked for. this results in the grid making a 2nd redundant call to transformRequest(), again passing in 951 and 1000 as the startRow and endRow. On this 2nd call, this.previousCriteria is equal to the passed in criteria (since it was already updated on the 1st call), my code for resetting paging will not execute, and the invalid startRow and endRow are passed to the server, bringing me back to the original issue.
So I am currently living with the fact that the user must scroll up to the top of the grid in order to see the filtered results.
What am I missing here? Is this a bug that's been fixed in a later release of SmartGWT? Is there a better way to make this work than my current hack in transformRequest()? I just want to reset the paging when criteria changes, make a single fetch request, and display the filtered results with the grid scrolled to row 0.
By the way, I have searched this forum and have found several similar posts, but none seemed to describe my exact use case.
Comment