Partial rendering is a small and simple AJAX framework living within the boundaries of classic ASP.NET. It offers a great way to add basic AJAX capabilities to ASP.NET pages, but it also suffers
from a number of limitations. I’ll present three areas of functionality where partial rendering just can’t do better than it does—and it can’t be improved because of some structural
limitations. Let’s start with the visual feedback provided to the user during update operations.
In a classic Web scenario, each postback requires a full page refresh. Every time the user makes a request to the server, she’s mentally prepared to wait. The browser freezes the current page, making it inaccessible to users. Operations then follow one another, but only one executes at a time.
There’s often no need for showing an update progress panel. The browser’s progress bar shown in the status bar is normally enough. Some sites—commonly travel Web sites—strive to offer a slightly better experience by using some nice tricks, such as using script to display an animated GIF (image) as the new page loads up. In any case, the user has clues of what’s going on. In an AJAX scenario, this is different.
The mechanics of the asynchronous postback keeps the displayed page up and running.
So the biggest improvement of AJAX—the continuous feel with the page—can become its major weakness if not handled properly. Having the computer engaged in a potentially long task might be problematic. Will the user resist the temptation of reclicking that button over and over again? Will the user patiently wait for the results to show up? Finally, will the user be frustrated and annoyed by waiting without any clue of what’s going on?
The partial rendering API comes with a helper control—the UpdateProgress control—that has been specifi cally designed to provide user feedback while one or more UpdatePanel controls are being updated. The control just displays a panel with some information about what is going on. You use CSS to style and position the panel at your leisure—for example, you can center it within the page.
The user interface associated with an UpdateProgress control is displayed and hidden by the ASP.NET AJAX framework and doesn’t require you to do any work on your own. Here’s the structure of an UpdateProgress control:
<asp:UpdateProgress runat="server" ID="UpdateProgress1">
<ProgressTemplate>
. . .
</ProgressTemplate>
</asp:UpdateProgress>
The ASP.NET AJAX framework displays the contents of the ProgressTemplate property while the user is waiting for a panel to update. You can specify the template either declaratively or programmatically. In the latter case, you assign the property any object that implements the ITemplate interface. For the former situation, you can easily specify the progress control’s markup declaratively. You can place any combination of controls in the progress template.
However, most of the time, you’ll probably just put some text there and an animated GIF.
(See Figure 2-3.)
FIGURE 2-3 The UpdateProgress control in action
A nice feature to mention about the UpdateProgress control is its DisplayAfter property.
Through this property, you can control how long the framework should wait before popping up the progress panel. By default, the property is set to 0.5 seconds—meaning that if a partial rendering operation hasn’t terminated after 0.5 seconds, a progress panel will be displayed to notify the user about what the system is doing.
The UpdateProgress control is much less enticing than you might think at fi rst. The control is great at showing some free progress messages, but it’s not designed to be a gauge component. It’s merely a container for the user-defi ned panel that the ScriptManager control shows before the panel refresh begins and that it hides immediately after completion. If you’re looking for a real gauge bar to monitor the progress of a server-side task, partial rendering and the UpdateProgress control are not the right tools. As you’ll see in a moment, polling is one of the main drawbacks of partial rendering and polling is unavoidable for monitoring server tasks from the client.
Likewise, the Cancel button you see in the fi gure is less powerful than expected. It’s a
client-side button with a piece of JavaScript code attached. Here’s the typical code it contains:
function abortPostBack() {
var manager = Sys.WebForms.PageRequestManager.getInstance();
if (manager.get_isInAsyncPostBack()) manager.abortPostBack();
}
Download at WoweBook.com
The Sys.WebForms.PageRequestManager object is a JavaScript class that governs the
execution of any partial rendering calls. In the preceding code, this object checks whether an asynchronous postback is going on and then just kills it. As you can imagine, canceling the pending operation has no impact at all on what is happening on the server. All that it does is close the socket through which the browser will receive any response. In other words, if your postback triggered a transaction, canceling the client request won’t stop, let alone roll back, that transaction.