7 Oct 2007 12:18 PM #11
Excellent work!! Thanks for share!!
7 Oct 2007 2:52 PM #12
8 Oct 2007 12:09 AM #13
Great work! Thanks!
Im trying to use this filters in an autogrid (which reconfigures itself with metadata from server). Currently there seems to be a problem with calling addFilter() in the onMetaChange event of the grids store.
I cant see why the call of addFilter doesnt return, it just quits the onMetaChange event.
8 Oct 2007 8:08 AM #14
GridFilters does not load filters automagicly any longer. It is the responsibility of the getFilter method to locate and return the class for a requested filter. If you would like to enable dynamic loading of filters, overwrite this method with some form of synchronous script loader and return with the loaded filter class.
8 Oct 2007 9:14 AM #15
For some reasons, it's impossible to reach your site.
Can you please attach the plugin's source to the main post of this thread? Thanks in advance
8 Oct 2007 9:21 AM #16
Thanks for your quick answer.
Sorry, I didnt write the hole story: The filters are cleanly applied by addFilter.
The problem is when a value is supplied to the addFilter argument.
Seems to be that a value will cause the grid to be reloaded, thats of cause not quite useful while the grid currently loading.
I wanted to have a preset value when the data for the grid is loaded.
That way I want to achieve a state saving/restoring for the filters.
(Sorry for my bad english)
8 Oct 2007 10:48 AM #17
8 Oct 2007 10:41 PM #18
9 Oct 2007 8:44 AM #19
9 Oct 2007 10:08 AM #20
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.