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 ajax.net 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 ajax.net

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 ajax.net wasnt the best thing, anthem.net 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 ajax.net 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.

anthem.net
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 ajax.net call.

Atlas

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 anthem.net. I know it supports JSON parsing/stringify but dont yet know if it supports ajax.net type calls.
JSON is about to become the latest new tool in my IT toolkit.

My last web project had me hand-writing my own C# code to store lists of object properties in a hidden text field. Then JavaScript code to parse this information.

JSON is going to save me doing any of that work and let me pass arrays of objects between serverside code and JavaScript and back again.

I use the JSON parser/stringifier in AJAX.NET professional on the clientside to store an array of my C# objects into a hidden text field.

In the JavaScript I eval the hidden text field and his gives me back the array of objects complete with all the properties.

So now I can add new objects to the array in JavaScript, use JSON stringifier ( I use the one at www.JSON.org ) to put the array back into the hidden text field. Now my server code can use the Ajax.Net pro JSON parser to create an array of C# objects.

Only a couple of issues I found so far :
1. Eval is considered evil because it will execute any JavaScript code. www.json.org has a safer method call to do this, but it doesnt seem to work with ajax.net created JSON.

2. Ajax.net JSON Doesnt seem to work very well if I try and store dotnet DateTime type in objects, so I will avoid doing this.
DataGrid and CSS

I am currently writing a website in Visual Studio 2005 using C#. One thing that makes this satisfying is that a team of outsourced developers was fired so I could do the work instead !

Yes I know GridView has replaced DataGrid but I have the exact styling we want on the DataGrid from previous work, so unless I find a really good reason to change I will stick with the DataGrid for now. I use templated columns defined in markup ( doesnt everyone ? ).

Does anybody use the DataGrid in the way MS demos always seem to show. i.e. the user has to click on a Update link, then edit the row ( after a postback put in the edit boxes ), then click on save. Seems messy compared to the more natural way in which every cell in the grid is editable at once.

We certainly dont, instead the DataGrids ItemTemplate definitions contain TextBoxes ( or checkboxes or dropdowns ) rather than labels. Add some custom JavaScript to allow navigation to be done using the arrow keys.

More JavaScript allows rows to be deleted by the user with Control-Delete or new rows added with arrow down on the last row. Unfortunetaly postbacks are required to do this in the current code.

The major thing I am unhappy about is all those itemstyle-backcolour="whatever" e.t.c junk markup I have put into the datagrid to get the exact styling we want. Moving this junk markup to stylesheet rules and using itemstyle-cssrule tags worked fine on IE, but looked horrible in Firefox.

The markup output by DataGrid seems unneccesarily complex and not really designed for easy application of CSS.

I plan to experiment with this later, but for now at least it looks perfect on Firefox, Opera and IE even if the markup isnt beautiful if you view source.

Maybe I will play with a CSS Control Adaptor class sometime, ideally I want absolutley semantic markup with enough cssclasses defined so I can get it looking exactly right with Css only.