Author: Herwig H10162
This is the first post in a short series on using the jqGrid jQuery plug-in with ASP.NET MVC. In this short introduction I will describe the plug-in, list some of its strengths and weaknesses, and explain why we selected it for our MVC applications. In the next few days, I will give detailed information about how to use the grid in your own applications.
jqGrid provides a nice-looking grid with built-in features such as sorting, editing, search, drill-down, tree lists, and more. It is based upon jQuery and integrates well with ASP.NET MVC. The grid is dual-licensed under both the GPL and MIT licenses (just like jQuery), so it can fit well into both commercial and open-source projects.
If you want to display tabular (grid) data with paging in an ASP.NET MVC application, there are essentially three choices:
- You can write your own grid components using HTML tables, links, manually-implemented paging, etc. This is actually less work than it might seem at first, and the first release of our ASP.NET MVC software did just this. But our own implementation lacked some of the visual flair of some of the third-party components, and avoided solving some of the harder problems, like in-line editing. Still, it was much easier than I expected, and worked well enough for our initial release.
- You can use a commercial component designed for ASP.NET. However, many commercial grid components don’t work well with MVC. Telerik has MVC demos available for their grid, and Developer Express has said that they intend to support MVC to some degree in the future. Even when the commercial components do support MVC at all, they don’t tend to make all of their features available in MVC applications, owing to the fundamental difference between the way ASP.NET MVC and “plain” ASP.NET work. If you are building a Web application on ASP.NET MVC, I would never recommend buying an ASP.NET component unless the vendor for that component is fully committed to supporting MVC. You cannot presume that any given ASP.NET component will work at all with MVC unless the vendor explicitly supports this.
- You can use a grid component which has no knowledge of ASP.NET at all. There are quite a number of these, generally built within the framework of one of the popular JavaScript libraries, and it is, ironically, easier to use one of them within ASP.NET MVC application than it is to use a grid component designed for ASP.NET (but not necessarily MVC).
As I said, we ended up choosing jqGrid. We were strongly influenced by the fact that we already use jQuery extensively in our application. There are several grid plug-ins available for jQuery. jqGrid has a number of advantages over the others I’ve seen, however:
- Supports three different models for editing data within the grid: Single-cell editing, in-line row editing, and editing within a pop-up form.
- Unlike some of the other jQuery grid plug-ins, jqGrid has decent documentation and a large number of demos with source code.
- You can display a simple grid, a “sub grid” (drill down), or a treeview.
- AJAX paging is supported in a number of different formats, including JSON, XML, or JavaScript objects via a custom function.
- The grid is updated very regularly, and a new version, with support for the jQuery UI theming library is under active development right now.
- Tracing through the grid source code is quite easy to do with Firebug, which is useful for figuring out things which aren’t quite covered by the documentation.
The grid also has a few downsides:
- The API is a bit of a mess. Capitalization (significant, in JavaScript) is so varied that it seems almost random. Portions of the code were clearly written by different people with limited collaboration with the original author of the grid. There is no consistent naming convention, and similar functionality is sometimes invoked in wildly different ways. For example, you set the grid height with a custom method,
setGridHeight, instead of the jQuery methodheight. But you reload the grid’s data with a jQuery method,trigger, passing the string"reloadGrid"as an argument. It’s a good thing the grid has decent documentation and includes source code, because you’re going to need them. The API is just not discoverable.
- Although the grid has quite a number of options for editing, it doesn’t necessarily play well with some of the other tools you may want to use in the context of editing, such as jQuery validation. (For starters, the in-line row editing doesn’t actually use an HTML form.) The three different editing modes (single-cell, in-line row editing, and editing in a form) use different source modules, different configuration options, and work differently. Doing editing in a way not explicitly supported by the grid can be challenging.
- Variable names in the source code use a lot of single letter and two letter abbreviations. This is quite common in JavaScript libraries, but it does make the source code a bit challenging to read.
- Although there is both free and paid support available, there is not a commercial company standing behind the grid. So don’t expect round-the-clock support, a toll-free phone number, etc.
After a good deal of experimentation with several grids, we decided to use jqGrid because it has considerably more features than every other grid we examined (when used in MVC application), and because we didn’t find any of its limitations to be show stoppers.
The next post in this series is LINQ Extensions. There, I show an extension method for IQueryable<T> which returns data suitable for the grid, without having to know anything about the type T.
Design. Code. Compile. Deploy.
Start Free Trial Upgrade Today
Free Delphi Community Edition Free C++Builder Community Edition
