Announcement

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

    Can i have an alternative UI for live grid filter?

    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)

    #2
    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

    Comment


      #3
      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.

      Comment


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

        Consider my filter event code, which works great, functionality wise:
        Code:
        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.

        Comment


          #5
          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.

          Comment


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

            Comment


              #7
              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.

              Comment

              Working...
              X