Asp. NET, custom script callback

Asp. NET client callbacks represent a neat and perfect way to execute server-side code without publishing and refreshing the current page. I discussed the asp.net callback in the Cuttingedge column in August 2004 and December, when it was discussed from the perspective of background callbacks to the server, sending input data to related pages, and receiving responses for rendering pages. The response string is then processed by the appropriate client and typically operates on the rendered page content through a Dynamic HTML (DHTML) object model and a callback JavaScript function embedded in the page.

Although this use of callbacks has been very exciting, they can perform more tasks. The script callback mechanism can also add advanced functionality to server controls. By implementing several interfaces, any custom control is given a script callback function to collect server data and update the user interface using a back-end, which is the topic I am going to talk about this month.

Inspired by the GridView control

If you've read a feature article I recently wrote Asp.net2.0gridview, you'll learn that the GridView control can display new record pages without refreshing the entire page. In fact, the GridView control provides an advanced engine for paging and sorting based on ASP.net script callbacks. The data for the new page is downloaded in the background and is not visible to the user. After the data arrives at the client, the data is immediately collected by the JavaScript function and used to update the current view.

Paging and sorting callbacks are not 100% client-side callback solutions (if you need a pure client implementation, see the article published in the February 2004 jeffprosise in the Wickedcode column). The GridView paging and sorting callback is on-demand, and it downloads only the data that is needed without downloading the entire data source to the client. You still have to pay a round-trip price, but you can guarantee the latest data, even if the data has recently been updated on the server.

I've been very excited since I found out that the ASP.net control can support script callbacks, and it's also prompted me to quickly find a way to build my own script callback.

By the way, the GridView is not the only asp.net2.0 control that supports similar functionality. Other view controls, such as TreeView, DetailsView, and FormView, can also provide the same functionality in other ways. As a developer with a callback functionality control, you do not need to work with server-side code, and you don't have to worry about writing and embedding JavaScript code in the host home page. The control can do everything, and it shows an intuitive programming model through which you can control the script callback mechanism.

Control script Callback Basic knowledge

Asp. NET script callback mechanism consists of two key elements: the server-side code that responds to user actions, and the JavaScript callback code that handles the results generated by server-side events on the client. In the case of the page callback itself, as I mentioned in the previous article, you can attach some asp.net generated scripting code to the page buttons that perform a postback that is not visible to the user. Because the target of the request is the current page, the page is published to itself, similar to how it behaves in a normal postback event, except that the page life cycle is shortened. The page must implement the ICallbackEventHandler interface so that you can invoke a method with a predefined signature to generate results for the client.

So what's the difference when a control triggers the Out-of-band? In this case, the target URL for the "invisible" postback is the URL of the page that hosts the caller control. The control must implement ICallbackEventHandler to provide a way to generate some results for the client. Similarly, the control is responsible for inserting any JavaScript code required to process the results and refresh the page in the hosting page.

A control with callback functionality is just a control that implements the Icallbackcontainer and ICallbackEventHandler interfaces, and each of the two interfaces has one method. The Icallbackcontainer interface has methods that can return script code that triggers a remote call, while the ICallbackEventHandler interface provides server-side code that executes during the call. ICallbackEventHandler is also an interface that must be implemented by a page with callback functionality. A custom control example that implements the callback interface is shown in the following code:

public class CallbackValidator : WebControl,
INamingContainer, ICallbackContainer, ICallbackEventHandler

In the implementation of the Icallbackcontainer interface, you might want to place a call to the page GetCallbackEventReference method to get a correct JavaScript call to start the server event. I'll tell you about that later.