James Senior's Blog

Last week we launched the ASP.NET Ajax Library Beta during PDC, oh and we donated it to the CodePlex Foundation under new BSD license (FTW).  As the email volume has been fading away running up to Thanksgiving in the US and everyone at work is recovering from conferences, I took this golden opportunity to sit down and build a small sample with the new library now that we are in Beta.

Since the ASP.NET Ajax Library takes care of JSONP requests for me (which enables cross-domain service requests) it is really easy to hit a service like the Twitter Search API which in turn provides me with a JSON result and a callback to trigger functionality which does something with the result.

This allows us to build a Twitter Search application that is running completely on the client-side depending on no servers apart from those at Twitter HQ (we kind of need them for the search results, remember).  In Part 1 of this 2-part series I will look at how to call the Twitter Search service using the WebServiceProxy.invoke method and then in subsequent posts I will look at using the data once in a DataView and how we can use client-side template to render the results.

First we start by exploring the WebServiceProxy.Invoke method – which is how we call the Twitter APIs.

The above code will make the required call to the Twitter Search API and takes a few parameters including an onSuccess callback function (doSomething) so we can then do something with the result set.  We can also specify things like the methodName (for webservice requests), query parameters, timeout etc – for the full set of params check out the MicrosoftAjaxWebServices.debug.js file.  Behind the scenes, the invoke method figures out if you are making a request cross-domain in which case we require the call to be JSONP so we can receive the callback on our end.

To get access to WebServiceProxy.invoke we need have referenced a number of scripts from the ASP.NET Ajax Library including MicrosoftAjaxWebServices.js.  The most sensible way to do this is to use the new Script Loader which takes care of loading not only this particular script but also any others from the library on which it is dependant.  It does this in a really efficient way both in parallel and asynchronously allowing scripts to be loaded but not executed according to a dependency tree.  Furthermore, you don’t even need to reference the Script Loader from a local folder or web server, you can grab it direct from the Microsoft Ajax CDN:

You’ll notice that we do versioning based on year and month so that your apps won’t break when we bring out new versions.

Once you’ve got the Script Loader referenced from the CDN, you can start bringing in the components you need and in this sample, so far, we need Sys.scripts.WebServices.  We use Sys.require to tell the Script Loader that’s what we need and also can provide a callback function for it to call once everything has been loaded and we are good to start using the script.

If we put all this code together and push one of the result tweets into a simple alert to show that it works, we get the following code:

Try it yourself by copy and pasting it into a blank HTML document, it’s that easy.

In the next post, I’ll show you how to do something useful with the result set by using the DataView component and client-templates.  Stay tuned.

For more information about the ASP.NET Ajax Library including samples, downloads and docs check out the wiki here: http://www.asp.net/ajaxlibrary

*UPDATE*

There is a bug in the beta where you need to include the following method to get the sample working.  Sorry to those who’ve been having trouble getting it working.  Add this to your javascript code and all will be right in the world.