Hello Kowal,
First of all, thanks for the great feedback. You can't imagine how much this helps us shape things up before releasing them officially.
1.
Logical Operator: I will let our designers know about that. Valid point.
2.
AddNew vs. ToComposite buttons: We will definitely think about that. Do you have any suggestions about how to change the layout so that it is more intuitive? We spend a lot of time on the drawing board thinking about the design and usability, but we can spend some more. So if you have any nice idea about how to rearrange things please tell us right away.
3.
Editors: Definitely on the to-do list. Just could not make it for the beta.
4. "
Member name (column name) isn't taken from Display attribute but is a property name": This is on my to-do list as well. Beta rush :)
5.
Poor binding to object properties: Could you please elaborate and give me an example, since I could not quite catch what you mean. RadDataFilter is unaware of any columns. It does not know anything about RadGridView either. It is totally disconnected from it. The only thing it does is manage a collection of FilterDescriptors. These FilterDescriptors could be either simple ones (the leaf nodes) or CompositeFilterDescriptors that allow a tree-like hierarchies.
Anyway, could you please prepare and and send me an example of this issue. Maybe a small dummy project or some code snippet. I would really like to know more about this.
6.
The link between a RadGridView and RadDataFilter: Now that is a tough one. This is by design. Let me try to explain it. I hope I will manage to.
Before going on I would like you to take a look at my
blog which describes the difference between a plain old IFilterDescriptor and its highly specialized sub-class called ColumnFilterDescirptor which has a very special meaning for RadGridView and RadGridView only.
Since RadDataFilter does not know anything about the grid-specific ColumnFilterDescriptors, it works with old plain FilterDescriptors. As described in the blog -- when you add a normal FilterDescriptor to the grid it
will be filtered, but the UI would not be updated because the UI "understands" ColumnFilterDescriptors only. They carry the information about the parent column of the filter so that the respective filtering control can read the information and update its visuals.
So there
is a two-way link between RadGridView and RadDataFilter, but RadGridView's UI will not pick this up. This is because RadDataFilter is totally unaware of and decoupled from RadGridView.
So when you add a filter to RadGridView through its UI, this will create an instance of the ColumnFilterDescirptor class. On the other end, RadDataFilter will display it correctly, but it will treat it as an IFilterDesciptor and nothing more. It is not a coincidence that the IFilterDescriptor interface resides in the Telerik.Windows.Data assembly which is used by all data controls. On the other hand the tightly specialized class ColumnFilterDescriptor class resides in the Telerik.Windows.Controls.RadGridView assembly and only RadGridView knows about its existence.
That is why, when you turn things the other way around and add a filter through RadDataFilter's UI, RadGridView will receive a good old plain IFilterDescirptor and will add it to its collection. This will definitely filter the data displayed in the grid, but the UI funnels will not be updated, because RadGridView is not sure which column was the filter meant for. I know what you are thinking right now, having the member name is not enough. I can provide examples about that.
Anyway, since RadDataFilter was designed as an
alternative of the column filters, I guess that you should choose one approach or the other. In other words, when you decide to let the user use RadDataFilter, simply turn off the filtering UI of the grid. In this way there will be no confusion.
The intention was to make RadDataFilter totally independent. So you can use it to filter a MS DataGrid, a ListBox, or any other ItemsControl. Inserting RadGridView-specific logic in RadDataFilter's source code will break this decoupling.
I am not sure that I managed to explain all of this well, but I really hope it makes some sense.
7.
The bloated issue: You are totally right here. This is on my list as well. The problem is that RadGridView creates some inactive filters well before they are needed and I will fix this as soon as possible. I will make RadGridView create a filter only at the moment it has been activated, i.e. the user types in something that makes sense. This will eliminate the huge tree of garbage filters. I will look into the exception being thrown as well. But once again, if you decide to use RadDataFilter, turn off RadGridView's Filtering UI. The next day you can decide to replace RadGridView with something else and you would still want things to work as before.
I am kidding -- do not replace RadGridView with anything else! :) :) :)
I mentioned three or four issues that are on my list. Now I would like to share that I have another 34 that I did not mention :)
Since this is a beta, I have still a lot of work to do until the control is ready to market. And your feedback is extremely valuable during this period, so I would like to thank you.
Please, keep it coming and thanks once again.
All the best,
Ross
the Telerik team
Do you want to have your say when we set our development plans?
Do you want to know when a feature you care about is added or when a bug fixed?
Explore the
Telerik Public Issue Tracking
system and vote to affect the priority of the items.