Waste Management

Improving Web Application Performance Using Client Callbacks





Waste Management

Improving Web Application Performance Using Client Callbacks


By John Paul Mueller


One of the biggest time wasters for current Web applications is that they usually send an entire Web page to the server for processing. In many cases, the entire refresh process affects a single control on the Web page. Consequently, refreshing the entire Web page wastes network bandwidth, server processing time, and even some client time. Developers often overcome the problem of having to send the page back to the server by performing processing locally using client-side scripting. However, this solution is limited because of client resources and the need to access server-side resources.


Fortunately, ASP.NET 2.0 provides an alternative in the form of client callbacks. A client callback replaces the information on only part of the Web page, rather than sending the entire page back for processing. In fact, the only information that goes back to the server is the information required to make a request. The only information the server returns is the data the client requires to display information on screen. Client-side processing manages the sending and receiving of data, so what you actually get is an extremely efficient data exchange that combines the best features of server-side processing with client-side scripts.


You can use client callbacks for any kind of data. For example, if you want, you can create a scenario where the Web page displays the current server time and automatically updates it once a second. Another example would be accessing a middle tier component that computes a quote for services based on the user s input and displaying the output on the Web page. However, this article discusses a more common example: database management. To keep things simple, I chose to use the Suppliers table from the Northwind database. The user will select one of the suppliers in the database and see the associated data, such as address, on screen. The main difference between this example and any other database example you might have seen in the past is that it never sends the entire page back to the server. Every new record is an update of the requisite controls on the existing Web page; only the required information passes between client and server.


Sending the Request

This example uses a few tricks you can use with other controls in many other situations. The first trick is to provide a means for making an ASP.NET control call a local script when it apparently doesn t support this feature. The example fills a DropDownList control with the list of company names. To perform this task, you must use the ASP.NET control, rather than an HTML control that lets you call a local script. Interestingly enough, Microsoft assumes you ll always want to use code-behind with the DropDownList control, but you can easily override that assumption by creating this control, as shown in Figure 1. Notice the onchange attribute. Because the DropDownList control doesn t actually support this attribute, Visual Studio will complain. However, when you compile and run the code, you ll find that the onchange attribute does work with the resulting


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.