Co-Sponsored by: Latest Features  • Custom Criteria  • JSON and XML  • Build a Message Box the AJAX Way: Part II  • Global Events  • Convention Over Configuration Article Rating Rate this article on a scale from 0 to 5 5 Best 4   3   2   1   0 Worst Email Tell a friend about this article!

Back Draft

Postbacks from the Edge

By Jonathan Goodyear

There are a lot of features about smart client applications that make them superior to Web applications. For instance, seamless application state, richer user interface options, and usage while disconnected from the network. When I’m working on an ASP.NET Web application, I miss all of those features (and more). I accept their absence, though, as justifiable costs of building an application where I don’t have control over the operating system on each user’s computer. However, one thing I cannot stand for in this day of modern application development is the antiquated page postback mechanism that almost every Web application uses. Although the pictures and fonts are prettier now, something about that just screams “Cobol green screen console application.” How dumb is it that we repaint the entire browser window whenever we submit some data to the Web server?

Thankfully, there is a better way to handle user interactions. Ever since Microsoft created the XmlHttp ActiveX component a few years back, there has existed a method to interact with a Web server asynchronously using JavaScript and DHTML. The technique was named Remote Scripting. Unfortunately, the technology was pretty raw and somewhat difficult to implement, so the concept didn’t get much traction early on. Even a wrapper for Classic ASP released by Microsoft, and a subsequent .NET wrapper released by Thycotic Software (http://www.thycotic.com/dotnet_remotescripting.html), didn’t do much to foster adoption. Limited marketing of the concept probably had a lot to do with it.

New life was breathed into the concept of asynchronous interactions with a Web server via Microsoft’s XmlHttp component and JavaScript when Google, seemingly out of nowhere, unveiled several new services (such as Google Maps, Google Suggest, and GMail) that leveraged them heavily to provide incredibly responsive Web user interfaces. A consulting company named Adaptive Path coined the term Ajax (Asynchronous JavaScript and XML; http://en.wikipedia.org/wiki/AJAX) to describe this old-yet-new interaction process (http://www.adaptivepath.com/publications/essays/archives/000385.php). In generic terms, Ajax dictates that a client JavaScript library brokers asynchronous communication between the user interface in the browser and the application logic on the Web server. This is in stark contrast to the common postback/render mechanism that most Web applications still use.

Developer excitement over the Google applications and the catchiness of the new acronym has finally led to the increasing usage of asynchronous communication in Web user interfaces that should have happened a long time ago. In addition, a developer named Michael Schwarz has developed a robust free .NET library that implements the Ajax methodology (http://ajax.schwarz-interactive.de/). The value-add there is that the Ajax.NET library does all the heavy lifting for you. All you have to do is label your server methods using an “AjaxMethod” attribute and add an HttpHandler definition to web.config that helps wire everything together. There are a couple of other small steps, but they are all very simple. The best part is that it works with ASP.NET v1.1, so you can use it in production applications today.

Some of you more astute readers may be asking, “What about the Client Callback Manager that is coming in ASP.NET v2.0?” It is true that the next version of ASP.NET will have out-of-the-box support for asynchronous Web server calls (http://www.extremeexperts.com/Net/Articles/ClientCallbacksinASPNETWhidbey.aspx). However, it isn’t as easy and straightforward to implement, nor is it as powerful as the Ajax.NET library. For instance, Ajax.NET uses the extensible JavaScript Object Notation (JSON) to enable your server-side methods to return complex data types. Common data types such as the DataSet and DataTable have already been implemented, and more are on the way soon. Most primitive data types are supported as well, so your custom business objects that implement them can be brokered back and forth with little effort. The Client Callback Manager in ASP.NET v2.0 can only return a string (likely in XML form) that you must parse to interpret the results. In my opinion, it’s not as clean of an implementation as Ajax.NET. Plus, you’ll have to wait a few more months before ASP.NET v2.0 ships in order to use it in production applications (unless you are willing to chance using the unsupported Beta 2 “Go Live” License).

The bottom line is that a couple of good options have emerged recently that abstract the gory plumbing of asynchronous JavaScript calls to the Web server from you. That, in turn, makes it a heck of a lot more compelling to explore more dynamic ways to interact with the users of your Web application. They almost surely won’t eliminate postbacks from our vocabularies, but they will significantly reduce their degrading impact on the user experience, thereby closing the gap with smart client applications even further.

Jonathan Goodyear is president of ASPSoft (http://www.aspsoft.com), an Internet consulting firm based in Orlando, FL. Jonathan is Microsoft Regional Director for Florida, a Microsoft Certified Solution Developer (MCSD), and author of Debugging ASP.NET (New Riders). Jonathan also is a contributing editor for asp.netPRO. E-mail him at mailto:jon@aspsoft.com or through his angryCoder eZine at http://www.angryCoder.com.