Hello,
I'm using Kendo grid (and other components) through the MVC wrapper. Recently, I started using sorting and filtering, in the following way:
.DataSource(dataSource => dataSource.Ajax()
.Read(read => read.Action(action name, controller name)
.Sort(blah blah)
.Filter(blah blah)
)
All sort/filter operations are server-side. (obviously, I'm not going to dump a million records into the browser and have javascript filter them...)
Questions:
1) Sort and Filter MVC calls take the view model fields, which eventually fill the DataSourceRequest. How exactly does that translate through the dynamic linq into sql? Does it rely on the assumption that the name of the field in the view model will be the same as in the data model?
I mean, if I use something like
dataSource.Filter(filter => filter.Add(viewModel => viewModel.MachineId).IsEqualTo(machineId));
and later the request object (with field names as strings) with those filters, sorts etc goes into .ToDataSourceResult(),
how does it know which field in the data model - in the Entity Framework entity, that is - does the viewModel.MachineId map to?
For myself, I use AutoMapper, so through the mapper configuration, I know which field is which... but Kendo MVC side doesn't have that knowledge.
And if it makes an assumption about data model and view model field names being the same, how do I pass it the actual data model field name in cases when they aren't the same?
2) Is there any advantage to using extra parameters in the controller call, to filter the data, versus using Filter(), so that all the filtering info ends up in one and the same object, the DataSourceRequest?
If I add extra parameters to the controller call, I need to implement a separate controller call for each combination of parameters. And, in each call, I have to add all the sql conditions myself. If I can just use Filter() in the grid definition, I can keep reusing the same controller call for all combinations.
And, theoretically, through dynamic linq, when the data request object is passed into .ToDataSourceResult, this should result in all the "where" conditions being correctly applied, and the filtering performed in sql, on the sql server side... or am I wrong here?
Yet, your code samples with master/detail grids (a master grid with a detail template which contains another grid) used a separate controller call with the parameter; is there a reason for it, if it could have been simply filtered by this field?
3) How would I use Filter() in a grid / data source defined in the detail template of another grid?
The problem here is that related operators, such as IsEqualTo(), expect me to know the value on the server side, at the time C# is executed.
However, in a grid detail template, for the detail grid construction, this value is only known on the client side.
A call like .IsEqualTo("#=template_field_here#")) won't work; the argument is obviously a string, yet the .IsEqualTo expects the argument to be of the same type as the field I'm filtering... which makes sense only if I knew it on the server, outside of the detail template.
Would I have to write the whole detail grid in jquery?
(Yes, I could - and I did - write a separate controller call, with extra parameters, to accomplish this; I'm just trying to remove that code, if I really don't have to do it that way... if it can work simply through filters in the DataSourceRequest)
3 Answers, 1 is accepted
1) The Grid create the filter/sort/group/etc. expressions based on the model that is set to it:
@(Html.Kendo().Grid<Kendo.Mvc.Examples.Models.CustomerViewModel>()The above is the only option for the Grid to be able to create the filter expressions (or with server binding, the type of the model bound to the Grid).
I have to say that if there is custom mapping in the model, you need to ensure that the names do match exactly. Otherwise, you will have to manually change the names of the expressions in the DataSourceRequest object passed in the Read action.
2) Passing additional data to the Read action is something that the developer should decide if it is needed or not. The additional data could be used for performing some custom filtering over the data before calling the ToDataSourceResult method over it or perform any other operation. It really depends on the exact requirement. The default parameters are the ones that the Grid passes for the currently applied expressions in the DataSource and it makes the query within the ToDataSourcResult based on those parameters.
3) Setting initial filter in the child Grid from the parent dataItem will be possible only for string type, because the binding expression that will be populate from the parent row could only be defined in a string. With that in mind, passing the additional data or filtering the child Grid on client-side manually will be the only option.
Hope this helps.
Regards,
Konstantin Dikov
Progress Telerik
Rank 1
Okay, this clears the picture. Thanks!
I have a simple proposal for names in the view model... you could define an attribute, which the developer could apply to a property of the view model. The attribute would contain a string, which represents the (different) name of the same field in the data model.
Then .ToDataSourceResult can check for that attribute, and, if present, use the string from it instead of the name of the property from the view model. If the attribute is not present, you default to the name from the view model property (as in, default to the same that you do now). Simple? This should be very easy to implement.
An advanced version of this would be that the attribute can also contain some sort of a function (supplied by the developer) that does more complex mapping (type changes and whatever).
As for the filter in the child grid, can you do something similar to what you already do in other places... have another MVC wrapper Filter function (on the data source) that lets me pass a string that is not the literal value, but a javascript function - either the name of a javascript function, or the function itself, something like "function() { calculate and return some data here }", and the value from that would then go into the value of that filter?
Regarding your suggestion, you could share your idea in our public feedback portal, where other developers could vote for and share their view on the scenario:
As for the filter, you could handle the "Filter" event of the Grid and manipulate the filter expressions:
Regards,
Konstantin Dikov
Progress Telerik