FilterEditor with TextItem has selected value after filtering

[chellegaard]

Hi there,

we are using smartGWTPro 4.1 and have experienced a peculiar case with ListGrid's FilterEditor.
We're using the FilterEditor with a TextItem, which has an KeyUpHandler that triggers filtering with the FilterEditor's criteria combined with some user criteria obtained from a series of CheckBox'es.
This is why we use this setup instead of just using ListGrid.setFilterOnKeypress(true) for the FilterEditor...

Anyway - it works as we would expect when running in the debugger: when we type in the filterEditor the filtering is triggered with the FilterEditor's value as criteria and when completed the TextItem is still in focus (and the value is NOT selected).
But when we compile the application and run it in a production setup - the text value in the FilterEditor is selected after the filtering :/
Why this difference and how do we unselect the text value in the FilterEditor??

We've tried using deselectValue() on the TextItem (inside a FocusHandler), but oddly it throws an exception:

self.deselectValue is not a function

Maybe we've missed something in the API docs - but still that doesn't explain the different behavior between debugger/compiled mode :/

[Isomorphic]

Sorry, this is not enough information to work with - please take a look at the FAQ for the information you need to post in order to allow people to help you.

[chellegaard]

Ok fair enough - let me try to elaborate:

The 2 attached files show the difference we're experiencing. The compiled version selects the filterEditor text when the filtering completes (right after "Loading..." message disappears) - whereas the debugger version doesn't.
We really want the behavior from the debugger version - as the user can keep typing without replacing the selected text.

Ohhh - and we updated to the nb-build of smartGWTpro 4.1d from 3/2-2015!!

Let's have a look at the code - starting with a ListGrid with a FilterEditor (and local data source).

piGrid = new ListGrid();
...
piGrid.setShowFilterEditor(true);
piGrid.setDataFetchMode(FetchMode.LOCAL);

We use a custom TextItem for the FilterEditor in order to combine Criteria with some user settings.

piNameFieldFilterTextItem = new TextItem();
piNameFieldFilterTextItem.addKeyUpHandler(new KeyUpHandler() {
	@Override
	public void onKeyUp(KeyUpEvent event) {
		if (KeyUtil.isKeyToBeProcessedInFormItem(event.getKeyName())) {
			piNameFilterStr = (String) event.getItem().getValue();
			updatePiFilters();
		}
	}
});

The ListGridField is simple enough:

piNameField = new ListGridField("piName", "Performance Indicator");
...
piNameField.setCanFilter(true);
piNameField.setFilterEditorProperties(piNameFieldFilterTextItem);
piNameField.setFilterOperator(OperatorId.ISTARTS_WITH);

The updatePiFilters() method combines existing user specified criteria with the FilterEditor text before performing the filtering.
We've tried to explicitly call TextItem.deselectValue() following the filtering - but this has no effect. Debug-version still does not select the value in the filterEditorTextItem, while the compiled one does :/

void updatePiFilters() {
	//setting up other criteria
	List<Criterion> criterions = new ArrayList<Criterion>();
	criterions.add(someCriteria);
	criterions.add(anotherCriteria);
	criterions.add(aThirdCriteria);

	//add any text from filterEditor 
	if (piNameFilterStr != null && !piNameFilterStr.equals("")) {
		criterions.add(new AdvancedCriteria("piName", OperatorId.ISTARTS_WITH, piNameFilterStr));
	}

	AdvancedCriteria filter = new AdvancedCriteria(OperatorId.AND, criterions.toArray(new Criterion[criterions.size()]));
	piGrid.fetchData(filter);

	try {
		piNameFieldFilterTextItem.deselectValue();
	} catch (Exception e) {
		// ignore
	}
}

[Isomorphic]

This is an odd way of doing things - use listGridField.filterOnKeypress if you want filtering on each keystroke. Use a FilterSubmitHandler if you want to customize how filtering is done, not just a call to filterData().

[chellegaard]

The approach you mention is actually the first one we took ;)
BUT we couldn't make it work: we found no easy way to combine the FilterEditorCriteria from ListGrid.getFilterEditorCriteria(); with criteria from "other sources" - like the criteria we construct according to a series of checkboxes.

Bear in mind we also call the updatePiFilters() method, when the user changes one of these settings, ie. it's not triggered by a FilterSubmit.

We see no easy way to update an existing FilterEditorCriteria from a prior filtering - the criteria for FilterEditorCriteria just keeps growing and we end up with several criterias for the same fieldNames - which of course breaks correct filtering :/

We are actually quite happy with the solution from our previous post - as we build a new criteria before each filtering with manually constructed criteria for both the TextItem-value in the FilterEditor and all the "external" user settings. This solution suits our purpose when running in the debugger. But like we said - we just don't understand why the TextItem's value would be selected after the filtering when running in compiled mode :(

[Isomorphic]

The problem with just calling filterData() during the processing of some random keyUp event is that you are in effect telling the grid that entirely new criteria are being applied, unrelated to any user action in the FilterEditor. It's a natural thing that, with an apparent complete change of criteria, the criteria would become selected so the user could start modifying it.

We're not following why it would be more difficult to modify the criteria in the midst of a FilterSubmitHandler vs in a KeyUp handler - there doesn't appear to be a reason this would be tougher. Please take that approach, which is what we document.

If you still have the same problem using the documented approach, try putting together a test case based on a product sample that demonstrates this selection issue, and we can take a look.

[chellegaard]

Well actually we also want to apply new criteria unrelated to the FilterEditor, as we tried to explain ;)
Therefore we just can't rely solely on the FilterSubmitHandler.

In our case we apply a filter criteria on loading based on the user's settings of the CheckBox'es saved from the last visit. This initial filter has nothing to do with the FilterEditor, as the user hasn't had the chance to use it yet.

If the user then after the loading of the page type some filter text value this generates a criteria - that is appended to the existing.

But what happens then, if the user changes the CheckBox settings?? - there is no easy way through the API to alter existing criteria. Look at the criteria object here::

{_constructor=AdvancedCriteria, 
 operator=and, 
 criteria=[{fieldName=isnormal, operator=notNull}, 
			{operator=and, criteria=[{fieldName=observed, operator=iContains, value=yes}]}, 
			{fieldName=iskey, operator=notNull}, 
			{fieldName=piName, operator=iStartsWith, value=c}]}

This is derived from the initial criteria and a typing of "c" in the FilterEditor. If the user than changes the isnormal criteria through an event unrelated to the FilterEditor - how would we easily update this Criteria, when we grab ListGrid.ListGrid.getFilterEditorCriteria()??
By breaking down the different Criteria of the combined Criteria, removing the 1 for isNormal and adding a new Criteria maybe??
In an ideal world we would have liked some functionality for this in the API ;)
...or are we missing something??

[Isomorphic]

Modifying the criteria from the filter editor in order to add additional criteria is one of the primary use cases that the FilterEditorSubmit API was designed for. That's why we keep telling you to use it.

We're not sure what your concern is about modifying the criteria. You can see what the criteria is, and you know what you want - now just write the necessary code. It's just a variation on the code you already had in your KeyUp handler.

[chellegaard]

We understand what you are trying to say - but the criteria obtained from piGrid.getFilterEditorCriteria() is not easy to alter.
The API only lets us add new criteria - we really need to alter or remove one of the existing criteria in the inner Map, when the setting for this criteria has changed.

But anyway - we have a new solution now - that actually doesn't need the FilterEditorSubmitHandler at all.

At page load we construct the AdvancedCriteria combined from the loaded settings as explained before and then do the filterData(). Setting ListGrid.setFilterOnKeypress(true) now works on it's own without the SubmitHandler - but of course the filter criteria is now both the TextItem criteria from the FilterEditor and the predefined criteria. Only when the user alters any of the settings from a form outside the grid are the whole criteria rebuilt (and also with the TextItem criteria from the filterEditor).

This way there is no rebuild of the entire criteria, when the user is typing away in the FilterEditor-TetxItem. ...and lo and behold it acts perfectly fine in debug mode - but STILL selects the TextItem value after every typing in the FilterEditor.

So the only difference to your "Live Filter" in the Showcase seems to be the criteria added to the Grid by the initial filtering - before the user can start typing in the FilterEditor and trigger the FilterOnKeyPress.

[Isomorphic]

Sounds like you have an alternate solution, but as modifying criteria, all you do is create a new Criterion that omits that particular sub-criteria.

[chellegaard]

This discussion got side-tracked somehow. We basically agree that the criteria needs to be manipulated/combined and applied to the grid.

We've now done several implementations and the latest seems the cleanest - but the whole point is, that the ListGrid selects the TetxItem value after filtering is done (the "Loading..." text is briefly shown in the FilterEditor TextItem before the filter value is inserted back in and then SELECTED).

Your "Live Filter" in the showcase works as we would expect (and as our debug version does) - but have you ever tried to apply other criteria beforehand as we do??

[chellegaard]

Don't know if you have given up on us - but we're basically back to square one on this problem :/

The funny thing is that using the Filter icon gives the expected behaviour - whereas typing in the FilterEditor TextItem, either when using setFilterOnKeypress(true) or initiating a filtering with ENTER, when not using FilterOnKeypress DOESN'T!!!

To summarize: using the filter icon does NOT select the TextItem value after filtering - while any filtering initiated by typing in the TextItem does!!

Seems there must be a small, but significant difference in your code...

[markok]

We stumbled on this issue too.

What I noticed is that in our case, the filter editor's text field only selects the entered text after filtering if our grid is grouped (?). When we ungroup the grid the issue disappears. We haven't found a real workaround yet - the issue is really frustrating for users as when typing too slow the text gets cleared (as the input selects the text the next key press overwrites the content of the input).

Have you found any solutions for this ?

We are using 4.0P NIGHTLY-2016-06-17.

[Isomorphic]

We were never able to reproduce a problem when using the suggested approach.

If you think there's an issue here, try creating a minimal, ready-to-run test case that reproduces the problem against 5.0 (the current version - 4.0 is too old).

[markok]

It seems to occur only with a big amount of data and when the "Grouping data ..." dialog appears & disappears.

Try this:

    public void doOnModuleLoad() {
        viewport = new VLayout();
        viewport.setWidth(500);
        viewport.setHeight(600);

        DataSource ds = new DataSource();
        DataSourceTextField pk = new DataSourceTextField("f1");
        pk.setPrimaryKey(true);
        ds.setFields(
                pk,
                new DataSourceTextField("f2")
        );
        ds.setClientOnly(true);
        Record[] records = new ListGridRecord[1000];
        for(int i=0; i<1000; i++) {
            records[i] = d(i);
        }
        ds.setTestData(records);

        ListGrid g = new ListGrid();
        g.setDataSource(ds);
        g.setDataFetchMode(FetchMode.LOCAL);
        g.setShowFilterEditor(true);
        g.setFilterOnKeypress(true);
        g.setAutoFetchData(true);

        final ListGridField f1 = new ListGridField("f1");
        f1.setWidth(50);
        final ListGridField f2 = new ListGridField("f2");
        f2.setWidth("*");

        g.setFields(f1, f2);

        viewport.addMember(g);
        viewport.draw();
    }

    protected static ListGridRecord d(int i) {
        ListGridRecord r = new ListGridRecord();
        r.setAttribute("f1", "" + i + "foo1");
        r.setAttribute("f2", "foo2 " + i);
        return r;
    }

Steps to reproduce:

1. Enter something to filter inputs
2. Observe that everything works, the text does not get automatically selected
3. Group the grid with some field
4. Enter something to filter inputs and observe, that the input content gets automatically selected