Excellent work!! Thanks for share!!
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.
Sencha Premium Member
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
Originally Posted by ambience
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)
Is there an easy way to preset the filters initial values, without triggering the events, so that the grid doesnt get reloaded?
Originally Posted by AlxH
Ext JS Premium Member
As this seems to be a common criticism (esp from ejetorix ), I just want to take a moment to defend my decisions =)
Originally Posted by ejetorix
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.