No announcement yet.
  • Filter
  • Time
Clear All
new posts

    Can i have an alternative UI for live grid filter?

    Consider your "live filter" showcase example:

    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)

    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


      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.


        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());
        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.


          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.


            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?)


              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.