ASP.NET Script Callbacks

ASP.NET 2.0 contains a native API, named ASP.NET Script Callback, to implement out-ofband
calls to the same URL of the current page. This API makes the out-of-band request look
like a special-case page request. It transmits the view state along with original input fields. A
few additional input fields are inserted in the body of the request to carry extra information.
Once on the server, the request passes through the regular pipeline of HTTP modules and
raises the expected sequence of server-side events up to the pre-rendering stage.

Just before the pre-rendering stage, the page method is executed, the return value is serialized
to a string, and then the string is returned to the client. No rendering phase ever occurs, and
the view state is not updated and serialized back.

ASP.NET Script Callback provides its own JavaScript API to wrap any needed calls to
XMLHttpRequest. As a developer, you are not required to know about this API in detail. As a
developer, you should instead focus on the programming interface of the GetCallbackEvent-
Reference method of the Page.ClientScript object. This method simply returns the JavaScript
code to attach to a client-side event handler to place an out-of-band call. The JavaScript code
also references another piece of JavaScript used to update the page with the results generated
on the server. But what happens on the server when the secondary request is made? Which
page method is executed?

ASP.NET Script Callback defines an interface—the ICallbackEventHandler interface—that any
server object that is the target of an out-of-band call can implement. The target of the out-ofband
call can be either the page or any of its child controls. The execution of an out-of-band
call is divided into two steps: preparation and results generation. The RaiseCallbackEvent
method of the ICallbackEventHandler interface is invoked first to prepare the remote code
execution. The GetCallbackResult method is invoked later in the request life cycle when it is
time for the ASP.NET runtime to generate the response for the browser.

All in all, the programming interface of ASP.NET Script Callback is a bit clumsy. Although the
programming interface shields developers from a lot of internal details, it still requires the
programmer to have good JavaScript skills and is articulated in a bunch of boilerplate server
code. You need server code to bind HTML elements to client-side event handlers, and you
need ad hoc server code to publish a programming interface that is callable from the client.
Each request carries with it a copy of the original view state and rebuilds the last known good
state on the server. In other words, the original value of all input fields in the currently displayed
page (regardless of any changes entered before the out-of-band call is made) are sent
to the server along with any parameters for the server method. Any out-of-band calls are processed
as a regular postback request up to the pre-rendering stage, meaning that all standard
server events are fired: Init, Load, LoadComplete, and so on. Before the pre-rendering stage,
the callback is prepared and executed shortly after. The requests ends immediately after the
server method executes. The view state is not updated to reflect the state of the page after
the out-of-band call and subsequently, it is not sent back to the client.

The advantage of using ASP.NET Script Callback is that it is a native part of ASP.NET and can
be easily encapsulated in server controls. For example, the TreeView control in ASP.NET 2.0
uses script callbacks to expand its nodes.

ASP.NET Script Callback is not free of significant issues, however. In particular, the server
method is constrained to a fixed signature and can only take and return a string. Sure, you can
place any contents in the string, but the serialization and deserialization of custom objects to
the string is something you must take care of entirely on your own. In addition, a page based
on ASP.NET Script Callback can have only one endpoint for remote calls. This means that if a
client page needs to place two distinct calls to the same remote page, you have to implement
a switch in the implementation of the ICallbackEventHandler interface to interpret which
method was intended to be executed.