Problem with pre-render filtering with more than 2 filters on a column using the CompositeFilterDescriptor

[Joakim]

Hi! 

I have been trying out the Kendo UI Grid using the MVC wrappers and I must say that so far Kendo UI Grid is a great product!

But I have stumbled upon a java script error: "Uncaught TypeError: Cannot call method 'set' of undefined" in the kendo.web.min.js file, it is a bit hard to debug considering I only have access to the minified version of the file.  

The error occurs when I'm applying more than 2 filters on a column using the CompositeFilterDescriptor, the filtering still works fine but the java script error is preventing all java script on the page to execute.

Code example:
var filters = new List<IFilterDescriptor>();

var cfd = new CompositeFilterDescriptor();
cfd.LogicalOperator = FilterCompositionLogicalOperator.Or;

//The error occurs if filtersToAdd contains more than 2 filters to be added to that column
foreach (var filter in filtersToAdd)
{
          cfd.FilterDescriptors.Add(new FilterDescriptor(Member, FilterOperator.IsEqualTo, FilterValue));
}

filters.Add(cfd);

return builder.DataSource(s => s.Server().PageSize(pageSize).Filter(f => f.AddRange(filters)));

Regards,
Joakim Thun

[Rosen]

Hello Joakim,

I'm afraid that I'm unable to observe such behavior locally. Therefore, you should provide a small runnable sample in which this error can be reproduced.

Regards,
Rosen
Telerik

[Scott]

I can verify that what you are see is a real issue. I have implemented code that allows a filter on complex data types. The code works fine when there are two or less filters. It seems that when there are more than two filters, the kendo javascript nests the compositefilterdescriptors. Here is my code...


public static void Deflatten(this DataSourceRequest dataSourceRequest)
{
    foreach (var filter in dataSourceRequest.Filters)
    {
       if (filter is CompositeFilterDescriptor)
       {
           // The code breaks on the next line with a null object when there are three or more filters
          foreach (FilterDescriptor filterDescriptor in ((CompositeFilterDescriptor)filter).FilterDescriptors)
          {
             filterDescriptor.Member = DeflattenString(filterDescriptor.Member);
          }
       }
       else
       {
          FilterDescriptor filterDescriptor = (FilterDescriptor)filter;
          filterDescriptor.Member = DeflattenString(filterDescriptor.Member);
       }
    }

    foreach (var sortDescriptor in dataSourceRequest.Sorts)
    {
       sortDescriptor.Member = DeflattenString(sortDescriptor.Member);
    }
}

I am working on code that will fix my specific issue and have not traced down why the kendoui code does this.

[Rosen]

Hello Scott,

Indeed, the CompositeFilterDescriptor's FilterDescriptors collection can contain any concrete implementation of IFilterDescriptor which includes the CompositeFilterDescriptor. Therefore, your code should accommodate for this and take the appropriate action and should not assume that the collection will always hold just FilterDescriptors.

Regards,
Rosen
Telerik

[Scott]

I think that you are missing the point. What is the logic for the nested nature of the Descriptors? While I have already written code (a recursive function) to account for the apparent behavior, it seems to me that there are never more than two Descriptors at a given level. For instance, I have set the following for a grid...

.Filterable(filter => filter.Extra(false))

If I filter 7 fields, the structure would be as follows...

CompositeFilterDescriptor
...CompositeFilterDescriptor
......FilterDescriptor
......FilterDescriptor
...CompositeFilterDescriptor
......FilterDescriptor
......FilterDescriptor
CompositeFilterDescriptor
...CompositeFilterDescriptor
......FilterDescriptor
......FilterDescriptor
...FilterDescriptor

Since I have no extra filters, one would expect the structure to be...

FilterDescriptor
FilterDescriptor
FilterDescriptor
FilterDescriptor
FilterDescriptor
FilterDescriptor

I'm okay with the complex first structure, but where is the documentation on how it is built so that I can code for it when I need to modify it's functionality. I don't see any reason for the complex structure and should a situation arise that I have not accounted for, my code just might fail gracefully.

[Rosen]

Hello Scott,

Generally speaking, the structure of the filter descriptors and its hierarchy is self explanatory. It just describes a filter expression. Thus, you should be able to recreate an arbitrary filter expression by reading the object hierarchy and its field without prior knowledge of initial filter set to the DataSource. 
There is no documentation on how it is actually build as it is irrelevant, it is an implementation detail which can be changed in the future but still to result in the same filter expression "logic". For example both of the following expressions produce the same result:

- (A == 1 || B == 2) || C == 3
- A == 1 || B == 2 || C == 3

On a side note the DataSource which is responsible for handling the filtering is decoupled from the Grid's UI,  thus it is not aware if Extra option is enabled or not. Both serialization on the client and deserialization on the server use a generic approach to process the descriptors.

Regards,
Rosen
Telerik