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.
 | |
| Figure 2. E-R Diagram: You can see the tables you need for the sample application and their relationship to one another. |
Implementing a Lookup
Assume you have a page that needs to fetch data from three tables: Region, Country, and City (see Figure 2).
This is a typical example of the “dependent list” problem. When a user selects a region the application should fill the Country list with countries from that region. Similarly, when the user selects a country, the City list should contain only relevant cities for the selected country. In other words, it’s a hierarchy in which each list’s contents depends entirely on the user’s selection from its “parent” list (see Figure 2).
It’s certainly possible to implement this scenario using the normal postback technique, but you’d have to put up with the slow performance of a complete page redraw for each request. Instead, you can provide a better, faster user experience using remote callbacks, because you can maintain all the page layout code, sending only relevant arguments and receiving only the relevant data.
Download the sample application that accompanies this article. The included callback.sql script configures a SQL Server or MSDE database with the data. Run that script first (you may need to alter the script for other databases). Then begin your implementation by starting up Visual Studio.NET Whidbey.
To create your project, select the template type “ASP.NET Web Site” (see Figure 3). This creates a page named default.aspx; rename it, if desired.
 | Making Client Callbacks You can now use this function from the client end to call back to the server, passing the relevant arg and ctx parameter values. However, you should also consider the changes in the RegisterClientScriptBlock declaration that occurred between ASP.NET versions 1 and 2. In ASP.NET v2.0 you can use the ClientScriptManager object associated with the page to register the script block. The Page.property ClientScript returns this ClientScriptManager object. You have two overloaded methods to choose from for registering scripts; here’s the one I chose for this example: Table 2 shows the meaning of the parameters to this call. Table 2. Parameter description for RegisterClientScriptBlock method.
|