Sunday, October 01, 2006

AJAX toolkit wars. I have played with AJAX before, first writing the JavaScript by hand and later by using the free, open sourced, Ajax.Net professional.

I loved pro as soon as I started using it. You just add a new HttpHandler to your web.config and markup the methods you want to be able to call from JavaScript with a custom attribute. You also have to enter one line of code into your page_load which registers the page ( or other ) class with

Now you can write JavaScript calls to that method. Synchronous or Asynchronous calls. Apparently it will allow methods which take/return any dotnet type including DataSets. I have only tried it with simple types.

Behind the scenes I guess it uses reflection on you registered classes to automatically generate JavaScript proxy functions which you call. The proxys hide away the communications layer and use of XmlHttpRequest. If you go the asynch root as well as passing in a JavaScript callback function you can optionally pass in a context object - this sounds very useful.

This weekend I found a few people saying wasnt the best thing, is the way to go ( also free and open source ).

An initial look suggests they are two totally different toolkits. Which gets used more will be decided by development needs on this project. It may well be the case both get used for different things.

Apparently you can markup server methods as requiring access to the session variables. Not sure what this does to traffic presumably it just causes the XmlHttpRequest to send back the sessionID as part of its load.

When calls a server method only a very small amount of data is sent to the server.
When the server method sends its results this traffic is also very low.
Its a web-service type call, i.e. little traffic and no context.
I will use this when it makes sense because it generates very small traffic.
This looks like the one to use, for example, if I wanted to be able to add a new row to a datagrid without a full postback.
It gives you a bunch of new controls e.g. anthem:DataGrid which subclass the dotnet ones.

All of a sudden the events which fire on the DataGrid do not cause full postbacks but instead are Ajax methods. But you can pretty much write serverside code as normal because relevant viewstate and the rendered control is passed back in this Ajax call.

Apparently the code behind this is quite small and neat and aims at making this look like a normal postback in your methods.

Of course this will use a lot more bandwidth than a stateless call.


Havent really played with this yet and probably wont until its final release. Only worry is it sounds a bit heavyweight in amount of code. Guess it may eliminate I know it supports JSON parsing/stringify but dont yet know if it supports type calls.

No comments: