client-side filtering

[kevboy]

I have a list grid that gets all its data using a custom DMI. I set it up to use client-side filtering. I also have a refresh button that forces an update from the server. However, when I click refresh, the filter I had previously typed into the grid's filter editors have no effect on the returned data. I tried setting a timer and adding a data arrived handler to filter the data but both didn't work. I had previously had a fetch callback which called filterData and that worked, but I had to use invalidateCache to force an update. Any thoughts? Thanks!

Paraphrased code:

ResultSet rs = new ResultSet();
rs.setUseClientSideFiltering(true);
// tried adding data arrived handler here but didnt work

final ListGrid grid = new ListGrid();
// ... set up other attributes
grid.setShowFilterEditor(true);
grid.setFilterOnKeypress(true);
grid.setDataProperties(rs);

Button b = new Button("refresh");
b.addClickHandler(new ClickHandler() {
  boolean first = true;
  public void onClick() {
    Criteria filterCriteria = grid.getFilterEditorCriteria();
    if (first) {
      grid.fetchData();
      first = false;
    } else {
      grid.invalidateCache();
      // tried creating timer here and calling grid.filterData(filterCriteria) but nothing happened
    }
  }
}

SmartGWT 4.0p 2014-01-15. FF 26. GWT 2.5.1

[Isomorphic]

Need some more of the basics posted:

1. do you see server contact after invalidateCache() ?

2. if you look at the RPC tab in the Developer Console, do you see the expected criteria? If so, perhaps the server response is just wrong

3. If the server response is wrong, can we see the logs and DataSource definition?

[Isomorphic]

Actually, here's a guess: maybe your server is not capable of doing filtering at all?

If so, you want dataFetchMode:"local" on the grid.

Setting useClientFiltering doesn't mean that client filtering is *exclusively* used. The normal, default mode is that client and server filtering are used in tandem (called Adaptive Filtering). dataFetchMode:"local" is how you tell the grid that the server has no idea how to filter and all data has to be fetched up front.

[kevboy]

Yup, that was it. Thanks!

[kevboy]

Thanks for the suggestion before.

Now I'm having trouble changing the operationId when it does a fetch after a call to invalidateCache.

I tried using ListGrid.setFetchOperation and then calling invalidateCache, but the fetch operation ID does not change as seen in the dev console.

[Isomorphic]

You'd need to call getResultSet().setFetchOperation() to make a dynamic change to the operationId.

[kevboy]

I tried ListGrid.getResultSet().setFetchOperation but I get a dialog saying I can't change that property after creating it.

I also tried calling ListGrid.setDataProperties with a new ResultSet and calling ResultSet.setFetchOperation, but the operation ID didn't get updated with that either.

[Isomorphic]

Hmm, you're correct. Because using a different operation may imply that basically anything about the returned data may be different, what you really need is a new ResultSet.

The simplest way to do this is:
1. set data to an empty RecordList
2. change fetchOperation on the ListGrid
3. call fetchData()

[jamesjara]

I'm not sure if this will work, but maybe I don't remember well..but looks more simpler to me.

With DSRequest you can change dynamically multiple settings.

DSRequest dsRequest = new DSRequest();
dsRequestSumarization.setoperatorID ---

if (invalidateCache) {
	invalidateCache();
}

fetchData(null, new DSCallback() {
	@Override
	public void execute(DSResponse response, Object rawData,DSRequest request) {
}
},dsRequest);

[kevboy]

Thanks jamesjara but I actually tried what you did before and it would make two fetches.

I got it to work using Isomorphic's suggestion.