Postbacks from the Edge

Back Draft

Postbacks from the Edge

By Jonathan Goodyear

There are a lot of features about smart clientapplications that make them superior to Web applications. For instance, seamlessapplication state, richer user interface options, and usage while disconnectedfrom the network. When I m working on an ASP.NET Web application, I miss all ofthose features (and more). I accept their absence, though, as justifiable costsof building an application where I don t have control over the operating systemon each user s computer. However, one thing I cannot stand for in this day ofmodern application development is the antiquated page postback mechanism thatalmost every Web application uses. Although the pictures and fonts are prettiernow, something about that just screams Cobol green screen console application. How dumb is it that we repaint the entire browser window whenever we submitsome data to the Web server?

Thankfully, there is a better way to handle userinteractions. Ever since Microsoft created the XmlHttp ActiveX component a fewyears back, there has existed a method to interact with a Web serverasynchronously using JavaScript and DHTML. The technique was named RemoteScripting. Unfortunately, the technology was pretty raw and somewhat difficultto implement, so the concept didn t get much traction early on. Even a wrapperfor Classic ASP released by Microsoft, and a subsequent .NET wrapper releasedby Thycotic Software (http://www.thycotic.com/dotnet_remotescripting.html),didn t do much to foster adoption. Limited marketing of the concept probablyhad a lot to do with it.

New life was breathed into the concept of asynchronousinteractions with a Web server via Microsoft s XmlHttp component and JavaScriptwhen Google, seemingly out of nowhere, unveiled several new services (such asGoogle Maps, Google Suggest, and GMail) that leveraged them heavily to provideincredibly responsive Web user interfaces. A consulting company named AdaptivePath coined the term Ajax (AsynchronousJavaScript 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 dictatesthat a client JavaScript library brokers asynchronous communication between theuser interface in the browser and the application logic on the Web server. Thisis in stark contrast to the common postback/render mechanism that most Webapplications still use.

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

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

The bottom line is that a couple of good options haveemerged recently that abstract the gory plumbing of asynchronous JavaScriptcalls to the Web server from you. That, in turn, makes it a heck of a lot morecompelling to explore more dynamic ways to interact with the users of your Webapplication. They almost surely won t eliminate postbacks from ourvocabularies, but they will significantly reduce their degrading impact on theuser experience, thereby closing the gap with smart client applications evenfurther.

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