Practical ASP.NET

Microsoft Contributes New Technology to jQuery

Microsoft and the jQuery team's announcements about the new data-driven plugins for jQuery have Peter all excited. He describes the plugins and what he's going to be doing with them in upcoming columns.

• By Peter Vogel
• 10/19/2010

On October 4th, Microsoft and the jQuery project issued a joint announcement about three new plugins for jQuery: client-side templating, data linking, and globalization. These three plugins are the first fruits of Microsoft's contribution to jQuery. Initially, to use the plugins you'll need to download them separately from jQuery itself (and, unless you're using Visual Studio 2010, you'll have to include the links to the jQuery library yourself).

The libraries are available for download from github: templates, globalization. Those libraries are maintained by the jQuery Core team (for templates and data link) and the jQuery UI team (for globalization). In jQuery 1.5, the libraries will become part of the jQuery Core Library and no longer require a separate download.

I'm not suggesting that globalization isn't important, but I'm most keenly interested in the data-driven features that are being baked into jQuery with templating and data linking. Data templating allows you to convert multiple data objects into multiple items displayed on the page. Data linking allows you to tie properties on data objects to properties on your UI objects. (Actually, it's any property on any client-side object to any property on any other client-side object, but it's the data support that I'm interested in.) This allows you to keep your data objects synchronized with your UI and vice versa. Data linking also includes converters that handle any data manipulation required in transferring the data between the two objects.

As I've said before, I think that we're seeing a new paradigm for Web applications: The user requests a page that is built on the server and sent to the browser with (perhaps) some initial data in it. The user then works with the data in the browser but the page isn't posted back to the server. Instead, JavaScript code in the page engages in a conversation with Web services back on the server to update and retrieve data. The user only posts back to the server when it's time to get a new page.

In the Microsoft world, the preferred technologies for this are ASP.NET/ASP.NET MVC, WCF, and jQuery. I suppose, in the long run, even retrieving whole new pages could be handled by requests to Web services, but I'm not ready to go there yet.

The evolution of this toolset to support this paradigm in ASP.NET has been rapid. Ten months ago, in the December 2009 issue of the magazine, I did an article on integrating ASP.NET, jQuery, and Web services, which led to a series of columns in January that built a jQuery-enabled page, which handled all the basic update/delete/insert activities for single and multiple records on a page following this paradigm. To build a page that handled multiple records, I used a third party library (jTemplate).

Four months later, I built the page again using the AJAX support Microsoft built into the release of ASP.NET for AJAX, which came out at the same time as .NET Framework 4... and then abandoned.

Well, "abandoned" is too harsh a word but Microsoft's commitment at that time to jQuery meant that there would be no further development with those client-side tools. On the server, I used ASP.NET and WCF Data Services (I used WCF Data Service primarily so that I didn't have to invest a lot of time in my Web services code). Last week's announcement is the "official toolset" that will support further development.

So, I'm going to build the page again, but this time using the new jQuery plugins. As readers pointed out in my series on ASP.NET MVC, this is one of the reasons developers like ASP.NET MVC as a platform for client-side development. So I'll be making at least a nod at the MVC world.

However, this technology is important not only because it makes things easier for developers, but also because it provides a common basis for tool developers. Just because you can create multiple record displays it doesn't mean that you should have to do all the work yourself.

In that earlier series on ASP.NET MVC, I made a comment that the right way to display multiple rows was to use a client-side gridview-like "control." It makes sense to me to look at one of those tools and show how it works in both of the ASP.NET (traditional and MVC) environments. And this doesn't complete the toolset, either, at least for me. As pages incorporate more code and become more sophisticated, the programming model in the page also has to mature to the point where it will support Test Driven Development.

However, the upcoming columns won't be "jQuery all the time". I've got a column coming up on debugging, another on comparing Crystal Reports and SQL Server Reporting Services, and two on working with the ListView control that was introduced in ASP.NET 3.0.