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.
Over the last four columns, I've used the new templating and data binding extensions added to jQuery to build an application that displayed multiple records while letting the user add and delete new records. Here are links to those columns:
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.
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.
About the Author
Peter Vogel is a system architect and principal in PH&V Information Services. PH&V provides full-stack consulting from UX design through object modeling to database design. Peter tweets about his VSM columns with the hashtag #vogelarticles. His blog posts on user experience design can be found at http://blog.learningtree.com/tag/ui/.