Printable View
Hi,
searched through the forum and the internet, and I haven't found a proper solution for the following problem in GXT3.0: we need to have the filter's input field in the header of a grid/column model instead of the header's context menu - unfortunately I haven't found a way so far to either add the filters to the header, or attach a text field in the header that sends its content to the filter so that all the "magic" like remote filtering etc. would work.
Anyone having an idea?
Br,
Günther
There is nothing too 'magical' about filtering - what have you tried?
The GridFilter classes are designed to work within the context menu - that's their purpose. However, they are built on top of other concepts that you can use to build your own functionality. The Filter class itself has a Menu internally, since it assumes that once the filter is checked, the user will want to pick one of several fields to use to filter.
How are you wanting to draw this? When doing a numeric filter, you can do a Less than, a Greater than, or a Equal to value - when you select the context menu for the Last column at http://www.sencha.com/examples/#ExamplePlace:filtergrid you see all three - how will these fit in the header? The Type column uses a ListFilter - how will you draw those checkboxes?
The only way I can see this functionality fitting in the header itself is by skipping all of that and only supporting a single text field, with some meaning - if that is the case, you *really* aren't trying to use the Filter and GridFilter classes, but a completely different functionality.
Next, are you filtering locally or remotely? In either case, you need to wire up the filter behavior slightly differently - I'll assume locally for the rest of this post.
The Store itself, either ListStore or TreeStore, can have StoreFilter instances given to it - this interface gives the store a way to ask for each item if that item should be visible. If any StoreFilter says 'no, this isn't visible', the item will be hidden - all filters have to agree to keep an item visible.
Use this as the basic primitive to change what items are visible in the grid. Each time the filter changes, you'll need to re-apply it to get it take effect - this might be each keystroke, or 2 seconds after the user stops typing, etc
Also look into the StoreFilterField - you might be able to use this and avoid directly building your own StoreFilter.
And finally, whatever wiring you end up building, use ColumnConfig.setWidget to add some widget to the column's header.
Thanks for the info. I'm not the one who chooses where the filters should reside, it's a requirement. As no one is filter for "less than" or similar, there is only one field used for the filter per column. We use server side filtering (approx. 60mio records joined with tables that have 20mio+ records). From your posting I now know where the journey has to go ;-) thx!
br,
günther
Sorry, I don't mean to suggest that it was your idea to begin with, just that there might be another way to phrase the UI, or that perhaps you didn't actually want the GridFilters feature, which seems to have more than you are asking for.
Since it is server-side work, you'll want to pass these filter directives to the loader, and possibly ask it to load again. This will mean building FilterConfig/FilterConfigBean instances based on each field - don't forget to remove the configs that are no longer in use (i.e. blank fields).
we have server side filtering already working with the gridfilter, so it shouldn't be too much of a problem to get it done with our own, new filters in the headers. thx a lot!