Can i have an alternative UI for live grid filter?

[mathias]

Consider your "live filter" showcase example:
https://www.smartclient.com/smartgwt...er_live_filter

Say i do not want the text field to be part of the filter editor just above the grid, but in a completely different place on the screen. I.e. i run my own form with a textfield and have a handler whenever the value in the field changes. Can i invoke the same filter events on the grid field i want to filter on manually? are you just calling filterData() or something else?

(obviously this more complex than just calling setShowFilterEditor and filterOnKeypress, but we're experimenting with the filter ui)

[Blama]

Hi mathias,

pretty sure this is kinda easy if you use the same DataSource (which you will surly do), as there is DynamicForm.getValuesAsCriteria().
Filter builder does a similar thing as what you are after, so this must be somehow possible.

Best regards
Blama

[Isomorphic]

Yes, very easy, just wire Changed notifications to filterData/fetchData(). You might the SearchForm.criteriaChanged() event, which intelligently fires after a brief pause in typing, like the FilterEditor does.

[mathias]

Great stuff thanks. May i take this opportunity to ask a performance/memory question?

Consider my filter event code, which works great, functionality wise:

filter = new SingleTextFilter(i18n.strings.a_Filter(), value -> {
    if(value != null && value.trim().length() > 0){
         Criteria crit = new Criteria(CSConstants.FIELD_FULLNAME, value.trim());
        grid.filterData(crit);
    }else{
        grid.clearCriteria();
    }
});

The changeevent code that you see is called whenever something is changed in the textfield. The "value" is the new string in the textfield.

This means that i evaluate the string and potentially create/clear a criteria on every keypress. Do you see this as an issue in general? I am not doing anything with the "old" criteria, will this cause mamory increase in the compiled javascript? Do you have any improvement suggestions?

Pointers appreciated.

[Isomorphic]

We would recommend adding a "debounce", that is, only calling filterData() when there is a hesitation in the user's typing.

SearchForm.criteriaChanged() has a built-in debounce, but other notifications such as Change / Changed do not.

[mathias]

Just curious - how do you wait for a hesitation without multithreading? when onchanged is called you can't be sure that the user will type again? You'd need a separate timer thread to check periodically?

(also, no memory issues with creating a bunch of new criteria() all the time then?)

[Isomorphic]

Criteria objects are simple and inexpensive. Under the hood, it's just a JavaScript Object.

To implement debounce, you just set a timer when Changed occurs. If the timer fires, you take the action (filterData()). If the Changed event happens again before the timer fires, you cancel the previous timer and set a new one.

The Scheduler and Timer APIs in GWT provide the ability to set timers.