I recently did a post Telerik’s HTML5 Kendo UI (Grid, Detail Template, TabStrip) which illustrated how to wire up their HTML5 Grid and handle server side paging. After doing so I quickly found myself needing to wire up the rest of server side bells and whistles e.g. sorting, filtering, etc.. Did some relentless googling and didn’t find any good resources on how to do this with MVC3 and EF4 so hence this blog post for the those of us that are doing just that. Rather than starting from scratch I’ll go ahead and continue where the my last blog left off.

So this first thing we need to do is configure our Kendo UI Grid for to do server side sorting and filtering so that we decompose what the requests pay loads look like coming from the Grid when performing these types of actions on it.

I’ve highlighted some of the major changes we made to our configuration which include setting up the Grid for server side actions: paging, sorting, filter, unsort and surfacing the filteration capabilities to the UI. Lines 54-72 is for setting up a Grid Toolbar which will contain a Kendo UI DrownDownList so that we can filter the Grid on ProductTypes which we will come back around to later on.

Now that we have the Grid configured for server side processing let’s take a quick look at what’s going down the wire in terms of pay loads for each of these actions so that we can mock up our models for these requests. When loading up IE Developer Tools (hit F12 or Tools > Developer Tools) and clicking on the Network Tab to start capturing network traffic we can see the actual pay load request for each of these actions.

So we can see that the pay load that is coming down the wire when a user performs a filter and sort on the grid is:

Note: Instead of downloading the LINQ Dynamic Query Library, you may want to actually download the sample application for this post because the DynamicQueryable.cs class from the Linq Dynamic Libray has been slightly modified to handle EntityFunctions to support string search actions from our Grid such as Contains, StartsWidth and EndsWith string searches.

A few quick notes in regards to our changes to our Action on our Controller to now support complete server side processing of paging, sorting and filtering.

This helper method will build our our where clauses and predicates so tha we can chain them up and pass them into Dynamic LINQ.

ToLinqOperator(string @operator)

This helper method will convert operators that are sent from our Grid to C# operators that Dynamic LINQ will understand and convert them for us

Lines 48-64, here we are iterating through the results to trim off the timestamp off of any properties that are of type datetime, so that when we do any grouping or filtering from the grid the timestamp of these fields are ignored.

Lines 88-103, here we are checking against the type of the column (property) that we are searching against so that we can convert the search criteria to the appropriate type. Currently we are supporting searches against types of string, datetime and int. If you need to add more types simply enhance this section of the implementation.

After some relentless googling for for a complete example of using Telerik’s new HTML5 Kendo UI Grid and MVC3 with server-side paging, I realized there isn’t an example anywhere on how to implement this including the Kendo UI documentation on Telerik’s site. Reason being is Telerik is really trying to set a strong message that the Kendo UI suite of controls is not coupled to any backend technology, they are really just pure HTML5 controls, all wired up with jQuery that makes request to your choice of restful like services e.g. oAuth (yes, Kendo UI controls supports oAuth out of the box).

So in short they will run pretty much on any browser with mobile gestures built in. I’ve been working with DevExpress ASP.NET WebForms and MVC controls for the past few years and I must admit that their controls, as well as many other 3rd party server-side control suites including Telerik’s can make your application somewhat bulky.

I think this pure HTML5 and jQuery direction from Telerik is a great idea, giving you the power of nice lean controls without the large footprint and clunkiness that your traditional 3rd party server side controls carry and last but not least let's face it, the timing is perfect, everyone is coding client side apps with jQuery especially when using MVC!

I created an empty MVC3 application and wired everything up in the Home/Index.cshtml view, let’s take a look at what’s all required to get a basic Kendo UI Grid up and running.

Now, let’s look at what the Grid is sending over the wire when requesting the payload for the Grid to bind by firing up an instance of Fiddler.

So from this we see that the Kendo Grid is making a GET request passing in parameters [take], [skip], [page], [pagesize]. Which now helps us frame up the controller, we now know that we have to provide a controller that accepts a GET request which takes in those parameters in order for us to do nice server side paging, meaning we will only ever return a max of 5 records for the current page you are viewing on the grid instead of returning all rows to the web server or in this case to the client browser and then do our paging processing there, minimizing the payload from our SQL box our web server. With that being said let’s wire up our ProductsController and while we are here, we will go ahead our implement our action for our detail grid which I will go over in just a bit.

Note: I’m using EF 4.3 (which you can get with NuGet, this was chosen because of the super fast prototyping ability you get with EF’s CodeFirst approach, CodeFirst was actually introduced in 4.1, 4.3 has some extra cool Migration features), so if you download the sample app and you’re wondering why there isn’t an *.edmx file, thats why! 🙂

Note: Rule of thumb, if you can’t accurately predict how many records will be returned in a service call that returns a collection, always implement pagination! You always want to have the smallest footprint in terms of payload going across the wire, whether it be the payload from your SQL box to your web server, or your web server to your browser or both.

You don’t want:

A non-performant app because of large payloads

Consumption of all the memory/cpu resources on your web box, for pagination processing on a large collection. Just think if your application is getting thousands of request and your web server is now responsible for pagination processing for all of them.

Consumption of all the memory/cpu resources on the client workstation on a large collection for pagination processing

So with that begin said perform pagination processing at the earliest stage, which is on your SQL box, apologize if I’m over emphasizing this, however, I’ve seen this bad practice implemented one to many times.

Notice, the [group] parameter in our action method above (which we are not using at the moment), if you enable server side grouping on the Kendo Grid, it will pass the field (column) that you chose to group on so that you can also perform server side grouping!

Let’s run the application

Great! We have the grid all wired up with server side paging in probably less than 10 minutes, all we had to do was paste in some jQuery configuration code, write an action that returns a list of products with skip and take which is trival with EF4 or pretty much anything that implements IQueryable.

This is pretty much the Kendo practice, which is providing a template that the Kendo libraries can interpret and inject into other places, in our case it will read this template and inject it into the Detail area of our grid.

Note: I’m using another Kendo UI control which is the TabStrip control to display a tab,
not neccessary however looks great so I added it to our detail view. 🙂

Add the following (highlighted) to our original jQuery config for our master Grid

line 3: inject the Kendo UI TabStrip in the div with Id: tabstrip from our kendo template that we used as our detailTemplate earlier

line 10: set service call to controller: ProductsConroller, action: GetProductDetails

line 11: map our properties from our entity to properties Kendo Grid, e.g. the Grid expects that your collection is mapped to [data] and that your total record count for that request is mapped to [total]

Notice that in the transport property we are setting the url to the MVC route: controller: Products action: GetProductDetails. Now with that being said we are only getting the precise payload and also retrieving it only on demand or lazy loading if and only if when the user clicks on a particular row to see the details of that row. This is very nice and lean request, not the typical behaivor you get when implementing a traditional ASP.NET WebForms 3rd party control where you have to load and instantiate the entire control tree, rebind almost every parent that leads up to the detail control, so if you haven’t already made the leap to ASP.NET MVC, you better start!

Let’s run the app and see the detail grid in action

There are plenty of resources on the all the configurations you can do on the client side for the Kendo UI Grid, however what I mentioned earier is that there is a lack of any artifacts on how to wire things up on the server side in our case which was MVC3.

Here are a couple of links if your interested in more of the client side configuration including events and API for the Kendo UI Grid.