I am excited to hear that a number of people have started using / extending the filters. If you have an extension (like some sort of panel based filter configuration) PM me with a link to the related thread and I will link it here. Thanks to every one who has helped bang out bugs and assisted newer users.
Also, I would like to credit ControlPath, the company that pays for my time =) The filters were developed to support an ongoing effort to transition the product to a 100% Ext UI and they were kind enough to let me share the code with you guys.
Server Side Code
Due to copyright issues I cannot share my implementation of the server side code (written in Java), and the PHP is to entangled in a bigger framework / hacked together to share. If you have an implementation you would like to share, PM me with the files and I will link them here.
Grid filters now function as a plugin for the grid. As a result you can use them in conjunction with custom views (like grouping).
List filters are now much more robust in that you can provide them with a Ext.data.Store to load their options the first time they are shown.
This version does not have a a dynamic loader included, read the source to find out where to put yours (documented).
The way filters are configured has changed ever so slightly.
Now 100% Ext (Prototype-free).
Local filtering can now be enabled by passing the 'local: true' as a config value
Fixed some of the filters setValue functions.
Stateful mode can now be enabled by passing a string value for the config option 'stateId'. This may be updated in the next Ext code push to store this information when the grid saves/restores its state. However, the events required are not part of the current beta (I think they are in SVN however)
Add an 'autoReload' field / config option that defaults to true. Set this to false if you wish to prevent the datastore from being reloaded when you make changes to the filters.
Version 0.2.1 (Minor update, thanks for the feedback) Bug Fixes
Date filters will disable conflicting date ranges [Thanks hendricd]
Added missing super constructor line to Filter [Thanks hendricd]
Boolean filters now use uniqu radio group IDs (so you can have more then one!) [Thanks olive38]
Added a 'serialize' event to the Filter class. Using this you can attach additional parameters to serialization data before it is encoded and sent to the server.
You can pass the GridFilters object as a plugin to the paging toolbar and it will reset the page to 1 whenever you update the filters.
Boolean filters take a defaultValue config parameter. Set this to null if you do not want either option to be checked by default.
Version 0.2.2, 0.2.3, 0.2.4, 0.2.5 Bug Fixes
Fixed an issue with numeric fields displaying "NaN" initially in RC1 [Thanks JeffHowden]
Fixed an issue with filter application in the absence of request options [Thanks JorisA]
Date format is now forwarded to the date selectors [Thanks hendricd]
Small bug fix with filters being activated before a load event on grids with the filters used as a plug in to the paging tool bar *inhale* [Thanks hendricd]
Perfect. I can't imagine a better way to do that.
But I think I've found a bug, try to do as follow:
1. Resize the width of one column making the last column not visible on the grid panel (a horizontal scrollbar will be shown)
2. Go to the second page
3. Create a filter in the "Visible" column to show just "No" visibles records
After doing that I can't remove this filter anymore because the scrollbar is gone and the grid will no longer show any data because I'm on the second page that has no records.
In this particulary case, going back to the first page after any filtering, solves the problem. But what if after setting a filter on the last column made the grid show no records? In this case I wouldn't be able to remove the filter anymore.
BTW, problems like krycek has noticed, are the reason for what i prefer a separate panel/region/whatever for filtering, instead of rendering it on columns menu.
As this seems to be a common criticism (esp from ejetorix ), I just want to take a moment to defend my decisions =)
While I agree the filters under the headers are perhaps more comfortable for users who are familiar with Excel, this method simply does not provide the space / flexibility we (the people at my company) need. For example, one of our columns represents an object in a directed acyclic graph. For which we provide the ability to filter on name, id range, or by selecting the object in a tree (rendered in place) and optionally include all children. One or more of these options may be active at any given time.(Screenshot 1&2) Or, in a much more simple example you have the list filter which can allow for the selection of one or more items to filter by. With out the filter menu, these options would be far to complex to express in the limited space under the headers. Additionally, chances are that if a grid is filtered it is because a user has chosen to filter it and I feel that having that information constantly displayed verbosely is unneeded clutter. Especially when, in the case of commonly filtered fields in a complex layout, you can us listeners and API driven filter activation to provider richer feedback about what the data shown represents (Screenshot 3)
Furthermore, I feel that the logical 'binding' of filters to an existing visual representation of the data key (the column header) is much easier for people to understand then disjoint spreadsheet of filters. While a separate tab could provide compound column filters and additional flexibility (AND / OR instead of just and); it has been our experience (as we've developed similar panels in the past) that that kind of power is confusing to must users and only leveraged by ... well mostly just the developers =\
I do appreciate feedback and will try to incorporate what I can into the filters to make them better. However (there's always a however), I am fairly confident in my decision to make them menu driven as opposed to panel/tab driven. This does not preclude a panel based tie-in. It simply means I my self will most likely not be developing it.
AlxH: Sure, post away. I am working on a grid state manager plugin myself that will have similar functionality. Though, I plan on using the setValue function to restore the state.
Lyardson: I have attached the two important files for parsing the filters and generating the required SQL. They are components of a much larger frame work which is losely based on WACT, so they won't function as is. But hopefully they should point you in the right direction =)