Tales from the Evil Empire

Bertrand Le Roy's blog

News


Bertrand Le Roy

BoudinFatal's Gamercard

Tales from the Evil Empire - Blogged

Blogs I read

My other stuff

Archives

How to deal with the July CTP ICallbackEventHandler breaking change?

As some have already noticed, there's been a change in the ICallbackEventHandler interface signature. The old interface had only one method, RaiseCallbackEvent, that took a single string parameter, and returned a single string response.

But this didn't work well with asynchronous data sources, where you need to initiate the request first and then act upon the results when they become available. There are no out-of-the box asynchronous data source controls in ASP.NET 2.0, but the data source interfaces are asynchronous-looking even if the implementation is synchronous. Third parties will no doubt construct asynchronous data sources. So we had to split the callback interface in order to enable it to play nice with asynchronous data.

First, you need to get the data by implementing the new RaiseCallbackEvent, which takes the same string parameter as the old RaiseCallbackEvent but does not return anything. This is typically where you'd start an asynchronous operation. If you're not, just store this data in a private variable for the moment.

Second, you need to use the data and render out the results of the callback by implementing the new GetCallbackResult, which takes no argument and returns the same string as the old RaiseCallbackEvent.

So if you already have code that uses the old interface, here's a very simple way to become compatible with the new interface while keeping your code relatively unchanged:

private string _callbackArg;

void
ICallbackEventHandler.RaiseCallbackEvent(string eventArgument) {
  _callbackArg = eventArgument;
}

string
ICallbackEventHandler.GetCallbackResult() {
  return
RaiseCallbackEvent(_callbackArg);
}

protected virtual string RaiseCallbackEvent(string
eventArgument) {
  // Your old implementation lives here unchanged
}

In a nutshell, take your old implementation and just change it from string ICallbackEventHandler.RaiseCallbackEvent(string arg) to protected virtual string RaiseCallbackEvent(string arg) and paste the code above.

Comments

Brock Allen said:

Hmm... Software isn't easy is it? :)

I doubt there's time left to do this, but I could imagine this being rolled into the Control base class to manage some of this complexity when not using the async model.

-Brock
# August 7, 2005 3:57 PM

Bertrand Le Roy said:

Too late for Whidbey, yes, but I'd be interested to read precisely what you have in mind (for, you know, Atlas or Orcas).
# August 7, 2005 7:33 PM