Unplanned
Last Updated: 20 Oct 2021 14:32 by ADMIN
Jeremy
Created on: 14 Oct 2021 12:51
Category: UI for Blazor
Type: Feature Request
1
TelerikCheckBoxListFilter should support different model than the grid model

I'd like to bind a model with a different field name to the TelerikCheckBoxListFilter in the filter menu.  Currently, this does not work because the Data has to have a member with the same name as the Field, which is used to update the filter descriptors.

 

Current Situation:

I have a single API for retrieving lookup values for the filters, that are always called on-demand (when the menu displays). This also supports cascading filter menus. If I want to supply the values back to filter menu I have to make specific code for each field on the model that I want to filter. For example, if I have a FlightNumber column it looks something like this...

public async Task<IEnumerable<object>> FilterValues_FlightNumberAsync() =>
       (await Service.GetFilterValuesAsync(nameof(MyModel.FlightNumber), GetLastGridRequest()))
       .Select(v => new { FlightNumber = v.Value });

The results of FilterValues_FlightNumberAsync() are then passed in via FilterData below (where @Field would be set to "FlightNumber")

<TelerikCheckBoxListFilter Data="@FilterData" Field="@Field" @bind-FilterDescriptor="Filters" />

This leads to a bunch of tedious code that should not be needed... A specific FilterValues_ function is needed for every column that needs to be filtered

 

What would be preferable:

Being able to use a single method to retrieve filter values. e.g.

public async Task<IEnumerable<object>> FilterValuesAsync(string memberName) =>
       await Service.GetFilterValuesAsync(memberName, GetLastGridRequest()); // returns something like LookupValue[] which is a generic LookupValue { Value  =... } class

 

To not break backwards compat, maybe could have an optional DataField parameter...

<TelerikCheckBoxListFilter Data="@FilterData" DataField="Value" Field="@Field" @bind-FilterDescriptor="Filters" />

This would take in LookupValues and and produce FilterDescriptors with MemberName set to Field

Or maybe event better, use generics and allow a callback to extract the filter value...

<TelerikCheckBoxListFilter Data="@FilterData" GetFilterValue="GetFilterValue" Field="@Field" @bind-FilterDescriptor="Filters" />

where GetFilterValue is a Func<TData, string> for example. 

===========

ADMIN EDIT

===========

We will most likely keep the Field parameter as is (pointing to the field from the Grid data that will be used to take the distinct options) and expose something like TextField parameter that will point to the field form the TelerikCheckBoxListFilter data containing the distinct options/labels.

2 comments
ADMIN
Nadezhda Tacheva
Posted on: 20 Oct 2021 14:32

Hi Jeremy,

Thank you for providing detailed explanation for the scenario and your expectations on how the feature would work!

As we consider that a reasonable request, I have marked its status as "Unplanned" - it indicates this is a valid feature not scheduled for implementation yet. As you are the creator of the post, you are automatically subscribed and will receive email notifications on status updates. Thus, you can easily track the progress of the feature.

Furthermore, as we are prioritizing the feature requests implementation based on the community interest and demand, I added a vote on your behalf to increase this feature's popularity.

In the admin edit of your post I also included some details on the most probable way the feature will be exposed.

I hope you will find the above information useful. If any further questions appear, please do not hesitate to contact us.

Regards,
Nadezhda Tacheva
Progress Telerik

Virtual Classroom, the free self-paced technical training that gets you up to speed with Telerik and Kendo UI products quickly just got a fresh new look + new and improved content including a brand new Blazor course! Check it out at https://learn.telerik.com/.

Jeremy
Posted on: 14 Oct 2021 15:31
I should also mention, that ExpandoObject can be used to work around this, but I was hoping to not have to resort to that.