Async Callbacks in ASP.NET 2.0 PDC Release - What's wrong with this picture?
I was talking to my mate Darren a while ago and I mentioned that I was thinking of writing an ASP.NET control to allow me to easily add asynchronous callbacks to my web forms without having to write much (or any) code by wrapping the WebService DHTML behavior. He flippantly told me that async callbacks were 'baked in' to Whidbey. I lost interest in my control idea but never got around to looking into the Whidbey callback facilities until the week-end. When I did I was a little bit disappointed. The way callbacks work is that your page implements an interface ICallbackEventHandler which requires that you implement a single method called RaiseCallbackEvent() . The page object also has a method called GetCallbackEventReference() for getting some javascript to perform the callback from the client which you can then register in your page. I wrote a sample which I put up on GotDotNet showing how to do this (it should be available soon).
The problem I have is with the method signature for RaiseCallbackEvent - it takes a single string as an argument and returns a string. This seems fundamentally flawed for two reasons - suppose you have two text boxes on a form (say a customer code field and a product code field) and you want to asynchronously return some data for each one when the user leaves the each box. Say for the customer you want to return the full name of the person and their shipping address to show to the user, and for the product you want to show the amount you have in stock. You can wire up each text box to call back to the server easily enough, but when RaiseCallbackEvent (which only takes a single string as an argument) is called how do you know who is calling you back? Is it the textbox with the product code sending you a product code and expecting the number of units you have in the shed, or is it the customer code text box calling back and wanting the mailing address for the customer? You can fairly easily get around this by sending some hard-coded string concatenated to the front of the “real” value you're sending back (the product or customer code in our example) and then parse it out on the server, but it is a bit of a kludge.
The second problem I have is that RaiseCallbackEvent can only return one thing, a string - no complex types, no collections, no arrays. Just a string. This leaves you in the un-enviable position of having to serialize anything else into a string and parse it out in client-side script, or forget about async callbacks for everything moderately complicated.
I know what you're probably thinking - this is all complicated stuff, you can't have everything. I would probably accept that except there already is a technology that lets you call back asychronously from client-side script, pass (almost) whatever you like, get back almost anything you like and have multiple end-points with no ambiguity as to why you are calling back (do I need to return a billing address, or is it a product quantity)? The technology I am refering to of course is WebServices and the WebService DHTML behavior.
All the things I've said so far are “as of the PDC release” - these problems may have been addressed already. Also there is scant to no documentation on any of this at this point so perhaps I have completely the wrong end of the stick. Also this API might have been designed more for control builders to add async. facilities to individual controls, rather than for page builders to add async facilities to whole pages. In the control scenario (which typically have a more singular focus) this method might be forgivable (but still not that great). As it stands RasieCallbackEvent seems pretty weak. Instead what about an attribute that you could add to a method that would make it a potential target for client callbacks, and have GetCallbackEventReference() and the page handle the wiring up? Does anybody know more about this API? Are there any changes pending for it in the beta versions?
Update: Here is my ASP.NET 2.0 asynchronous callback demo on GotDotNet
Update 2: Here is an article on DevX dealing with the Async. callback facilities in ASP.NET 2.0 “Whidbey” http://www.devx.com/dotnet/Article/20239/0/page/1 - the author does not seem to make any judgement calls regarding the design of this API, but the article is titled “Whidbey Simplifies Browser Client Script Callbacks“. Simplify is indeed the right word.