Whidbey Simplifies Browser Client Script Callbacks

here are plenty of good reasons to anticipate Whidbey, among which are a number of enhancements for client script support, including new attributes and a ClientScriptManager class to handle client scripts. However, perhaps the most welcome client-script enhancement feature is Whidbey's support for remote server callbacks using client script.

Refreshing or posting a page to do a data lookup is an extremely common technique. In classic ASP, developers used script to handle submitted data, which often made ASP code very difficult to maintain. Like most multi-page Web applications, posting form data to the server caused a complete request-response cycle, where the server would respond to the post with an entirely new page. The browser, naturally, would then render the new page in place of the existing page. This constant page-redrawing tends to make the user experience awkward and slow. One way that developers alleviated such interface problems was by using remote scripting, which used Java applets to make server calls in combination with DHTML's dynamic rendering to display updated or new data on an existing page. Alternatively, for pure-IE applications, developers could use client-side script with the XMLHttpRequest object to make background data requests. But both methods required non-trivial efforts, and debugging, in particular, was difficult.

Developers looked forward to some relief in the initial ASP.NET release—and they got some. Server controls, ViewState, automated postback, and the event-based ASP.NET model solved a lot of problems, and SmartNavigation (in IE-only applications) helped as well. But for cross-platform applications, developers continued to rely on remote scripting. In ASP.NET v2.0 (Whidbey), that has changed.

Whidbey's Client Callback Support

Figure 1. Flow of Callback: You can follow the route of the callback as it is handled by both server and client.

In Whidbey, clients can call a server method, pass data, and get results without posting a form. These calls use the XMLHTTP object in the background to make requests to the server, but you have to write much less special code to handle the calls.

Figure 1 shows the flow for the application logic. You write a client function (Step 2) to make a call to the server, and set up a custom server event (Step 1c) to handle this call. CallBackManager is an intermediary that handles steps 3 through 6, which includes the routing of the call from client to the server and pushing back the data from server to client. Another client function (Step 7) handles the response. Effectively, you write two client-side functions to make a request and handle the response.

To better explain how it works, here's how to set up a sample implementation of the callbacks.