Page 2 of 3   « previous page   next page »

As you can see from the above code sample, it is quite simple to use the XMLHttp object in a stand-alone manner. However, integrating the XMLHttp into the rest of the HttpPage life cycle is difficult - for example, how does one ensure that the server-side method being called has access to the state of other controls on the page? For the state of the controls to be correctly initialized, the callback handling on the server needs to go through a similar HttpPage life cycle as the postback. The other challenge in using the XMLHttp object directly is that as developers we need to account for different browser types. Fortunately, ASP.NET 2.0 provides a reusable pattern that makes the callback functionality easily accessible. Note that several controls that ship with ASP.NET 2.0, including GridView, TreeView, etc., leverage the callback capability.

Figure 1 depicts how the callbacks are implemented in ASP.NET 2.0. Let us start from the server side. A new interface, ICallBackEventHandler, has been defined. Any ASPX page (or a control that intends to support client callbacks) needs to implement the ICallBackEventHandler interface. ICallBackEventHandler defines one method called RaiseCallbackEvent. This method takes one parameter of type string as the argument and returns a string.

On the client side, to initiate the callback, a special Javascript function needs to be invoked. You can obtain a reference to this special Javascript function by calling ClientScriptManager.GetCallbackEventReference (see the second and third entries in the References section). The call to GetCallbackEventReference results in a reference to callback. When invoking the callback, you pass one parameter of type string. This is consistent with server-side RaiseCallbackEvent signature. That is all you need to set up callbacks from the client. The rest of the magic to hook up the client callback to the server-side RaiseCallbackEvent method of ICallBackEventHandler is done by the framework. The aforementioned special Javascript function for initiating callback uses two additional parameters to be included as part of the postback data - __CALLBACKPARAM and __CALLBACKID, which represent the string parameter to pass to the call and the ID of the control, respectively. On the server, ASP.NET detects the presence of the two additional parameters and routes the request to the appropriate control, resulting in the invocation of the RaiseCallbackEvent method on the target control. To solve the aforementioned problem related to initialization of controls on the page, ASP.NET runtime follows a trimmed-down version of HttpPage life cycle when servicing a callback. This includes going through the specific stages of page initialization, view state loading, page loading, and callback event handling. Once the callback event is handled by the control, the rest of the HttpPage life cycle stages are skipped.

To help better understand the ASP.NET 2.0 callbacks, included is a simple progress bar control that relies on callbacks to determine the status of a given task on the server. Listing 1 displays the code for the ProgressBar control. To support client callbacks, this control implements the ICallbackEventHandler interface. For the purpose of the demo, the RaiseCallbackEvent method implementation simply looks up a counter stored in the session, increments the counter by one, and returns the new value to the client. Finally, Listing 2 is the Javascript code that is responsible for initiating the callback. It uses this.Page.ClientScript.GetCallbackEventReference to obtain a safe reference to the function needed to initiate the callback.

Using client callbacks provided in ASP.NET 2.0, it is relatively straightforward to implement the progress bar control, since the data passing between the control and the client is a simple string. However, as soon as we start adding other datatypes to the mix, we will run into mismatches between Javascript and .NET-type systems. Unfortunately, the callback implementation in ASP.NET 2.0 does not help with this issue. Applications that want to use multiple datatypes, simple and complex, will need to implement a custom scheme on their own.

Fortunately, this limitation can be overcome by using an open source library called AJAX.NET (see the fourth entry in the References section), AJAX.NET implements a proxy-based approach for calling the server-side functions. AJAX.Net defines a custom attribute called AJAXMethod. When a server-side method is decorated with the AJAXMethod, a Javascript-based client proxy is automatically generated by the HttpHandler that is part of AJAX.NET library. Unlike ASP.NET 2.0, which supports a single parameter of type string for callbacks, AJAX.Net supports integers, strings, double, DateTime, DataSets, etc.

An alternative to AJAX.NET for dealing with differences between the Javascript and .NET-type system is suggested by Bertrand Le Roy (see the fifth entry in the References section). He has created a server-side control called EcmaScriptObject that recreates the Javascript type system in .NET. The idea is to reproduce a client-side object graph in .NET. This approach makes better sense as the conversion is happening on the server.

Even if we have a type-safe way to invoke callbacks, more challenges remain. Javascript is the glue that holds all the pieces of the AJAX application together. Thus, there is increased reliance on Javascript. Unfortunately, even though Javascript is a powerful and versatile language, it does not lend itself easily to well-known object- oriented principles. This means it is harder to achieve code reuse. Please refer to the sixth entry in the References section for syntactic sugar added around Javascript to make it appear as traditional OO language. Even then, it is hard to implement features available in managed languages such as events and delegates.

The other difficulty, as discussed earlier, is the lack of a reusable framework to make the Javascript development more productive. For example, wouldn't it be nice to have access to a Javascript-based UI framework that hides the differences between different execution environments? Another example would be a set of classes that make it easy to invoke Web services in a secure manner (as opposed to hand coding the SOAP packets and using XMLHttp to transport them).

Page 2 of 3   « previous page   next page »