Being Web 2.0 is a hot topic right now. So much so that everyone and their mom is out to dress up their web presence with whatever Ajaxy goodness they can. Lucky for the Internet the ASP.NET AJAX framework has made adding Ajax functionality to asp.net web sites and web applications a pretty simple task.

The simplicity is made possible because the framework hides much of the magical mechanics of doing the actual Ajax and DOM work behind a new control, the UpdatePanel.

However, like most magical solutions this one comes at a cost. Actually a couple of costs. Two of the biggest are server side performance and less control in the developer's hands.

Taking control out of your hands

For brevity lets ignore the performance issues and focus on the reduced control that UpdatePanel bring with it. To be clear, I'm talking about control of the client-side code and its interaction with server-side code.

As a result of the UpdatePanel hiding the mechanics involved with actually constructing, calling, and handling an Ajax request we lose much of the control that doing those things in a more manual way would provide.

Suppose I want to do some DOM manipulation before, during, or after an Ajax call. How would I do this with ASP.NET AJAX? The framework provides a couple of drag-and-drop controls that can be used to do some of the work, but its still far from the control I would have in a classic Ajax application.

In a more traditional Ajax application or framework I'd have control over how and when the request is made. I would also have direct access to the Callback methods that are invoked after the request is completed. But this leve of control isn't available with the UpdatePanel... at least not directly.

Actually, that's a bit of a lie.

Take back control!

The framework provides a new client-side JavaScript class that defines properties, events, and methods that can be used to on any page that has at least one UpdatePanel and a ScriptManager control. The name of this class - PageRequestManager.

Accessing the class from client-side JavaScript requires a single line of code:

var pageMgr = Sys.WebForms.PageRequestManager.getInstance();

A few of the most useful members the PageRequestManager class exposes are:

• beginRequest [Event] - Raised before processing of an asynchronous postback starts and the postback request is sent to the server.
• endRequest [Event] - Raised after an asynchronous postback is finished and control has been returned to the browser.
• isInAsyncPostBack [Property] - Returns a value that indicates whether the PageRequestManager object is processing a postback.

Check out the PageRequestManager documentation on the asp.net site for a full list of members exposed by the class.

Using the manager class

Subscribing to events is fairly straight forward. As an example I'll subscribe to the managers's beginRequest event so I can invoke some JavaScript before the Ajax request is fired.

pageMgr.add_beginRequest(BeforeAjaxRequest);

function BeforeAjaxRequest(sender, args)
{
    // do some cool stuff here!
}

To subscribe to an event I have to call the add_EventName method. In the above case I called add_beginRequest passing the name of the event handler as an argument.

A similar convention is used when accessing Properties. To get and set the isInAsyncPostBack property I would use get_isInAsyncPostBack() and set_isInAsyncPostBack(), respectively.

In conclusion

Hopefully this will help you take back some of the control that has been lost with the new UpdatePanel control.

Of course another option, and the one that I usually choose, is to not use the UpdatePanel and instead expose Web Services to the client-side script. Doing so allows me to maintain almost total control over the client-side code and it's interaction with the server.