Practical ASP.NET

Drawing Conclusions from the jQuery Extensions

Peter Vogel wraps up his review of the jQuery extensions by waxing philosophical about what those extensions mean to the kind of tools that developers should expect.

• By Peter Vogel
• 02/24/2011

• Implementing Deletes with Template Event Handlers
• Setting Up for jQuery Templates
• Displaying and Filtering Data with jQuery Templates
• Supporting Updates with jQuery Data Linking

The result was an application that offloaded much of its processing to the client, calling Web services to perform any server-side processing. The application is both more scalable (because more is done on the client) and more responsive to the user (because more happens at the browser). And because I'm using lighter-weight Web service calls (instead of doing full page postbacks) even my network burden is lowered -- and the application runs faster.

Ignoring the filtering ability that I build into the application and just looking at the updating functionality, what about this solution would change from one application to another? First, of course, the template for generating the table that displays multiple rows. More properties on the DTO would require more columns in the table and different controls in the template. In addition, the code that links the fields in the template to the objects retrieved from the Web service would need to be duplicated for each column in the template that supports updates. The optional conversion functions that I inserted between the form and the object would also change.

To support retrieving, updating and deleting data, the code in the Web services on the server would also change. But what in the client would change? From a structural point of view, surprisingly little. The parameters passed to the service that retrieves the data would be different from one application to another. However, the call to the Web service that deletes objects would always look the same, since it just accepts the primary key for the object being deleted. The same is true of the call to the update Web service: it just accepts an array of objects. The names of the method and the Web service would also change.

I recently wrote a book on code generation in .NET, so my first thought is how to create a code generation solution to implement this. It's easy to imagine a Wizard that, on its first page, would accept three inputs: The name of the Web service, and the three methods for retrieving, deleting and updating data. The Wizard would either read the WSDL file for the service or call the method on the Web service that retrieves objects to get a sample object. The Wizard would determine the list of properties on the object returned by the service.

The second page of the Wizard would list those properties and allow the user to select which ones to include in the template (and specify the HTML tag to use in the template). The user would also specify which property is the one to be used with the delete Web service. The third page of the Wizard would allow the user to specify where conversion functions should be inserted, generate skeletons for those functions, and incorporate those functions into the data linking code. An accompanying JavaScript library would include some typical conversion functions (e.g. my data validation code) that the user could add by checking off the function.

I'm not suggesting that I'm going to rush out and create this Visual Studio add-in, but it's certainly doable and would provide the kind of functionality that we've come to expect in server-side code. More importantly, this is a relatively simple Wizard -- any competent tool provider would create a far more sophisticated solution.

And that leads to one other benefit that falls out of these extensions. Tool vendors can build on these jQuery extensions rather than have to roll their own. Overall that should mean better support for client-side developers faster. Since tool developers would be building from the same base, their solutions would also be easier to integrate.

This won't happen next week, but I remain hopeful that 2011 will be the year that client-side development gets the same support that server-side developers take for granted.