On my way home from ASP.NET connections I converted  the Anthem Chat Example run with ATLAS using low level Web Service functionality along with script code. I've posted this demo along with the rest of the ASP.NET Connections demos here:

http://www.west-wind.com/presentations/scriptcallbacks/sample/Atlas/Chat.aspx

If nobody else is on when you're there, you have to open another window to have a conversation with yourself <g>. Imagine that - you can be Johnny the Cat!

I mentioned this before, a Chat application probably isn't the best example of what you should use AJAX technology for, because if this app were to get really busy it would really be a huge draw on server resources. AJAX is really a pull technology so it has to poll the server in order to be able to get update information of any kind, so this example pings the server every few seconds to see if there are updated messages for the client to display in the chat window. But I think it's kind of a fun example that demonstrates how the technology works really well because it relies on common AJAX elements such as polling and managing server driven messages.

This example is built entirely using the ATLAS Web Service functionality directly accessed from JavaScript code. It's not using ATLAS Server controls and it's only minimally using the ATLAS client framework. It does use the Web Service functionality extensively though to communicate with a ChatService that provides the basic messaging functionality for writing messages, retrieving message updates and displaying the list of users. Overall this is a very simple app, but there are a quite few different messages getting fired from client to server.

Compared to the Anthem Version of the Chat this version is much more lightweight though – it pushes only the message data over the wire as opposed to the actual control contents. The Anthem sample uses server logic only with minimal JavaScript code, while the ATLAS version uses mostly JavaScript code for the UI logic. Most of it though is pretty simple and functions are rather short. It's a different approach, but it's kind of interesting to look at both samples and see how each approach works which was the reason for the samples in the first place. In fact the Anthem example was meant to highlight the fact that it can be a real network heavy mechanism that can easily overload a site – issues that you have to be aware of when building AJAX enabled applications. You might want to hook up Fiddler and compare what goes over the wire with both.

The ATLAS sample uses pure JavaScript code – it doesn't use much of the ATLAS client framework and it doesn't use any XmlScript. In fact, I was thinking about this as I was putting the sample together – I don't think using XmlScript in this sort of environment would have a made a lot of sense actually. While there are events firing and the events update other controls, the update logic is not as simple as 'assign the result value from the service to this control' that is a big premise of XmlScript. Here a lot more things need to happen – Append a value to the existing value of a control. Clear out the content of a control, set focus, enable and disable controls, pop up a window and display content etc. All of these are things that not so easily addressed using XmlScript currently primarily because XmlScript doesn't seem to provide good support for calling raw JavaScript code. I think that will need to get much better in order for XmlScript to really be more useful – there are just too many things that declarative syntax is not going to be able to address easily.

It's interesting that there really isn't a lot of code to this. The client code makes the majority of it and most of that is actually a handful of utility functions (like a Shadow behavior function and the error display mechanism. The ASPX page has no code at all associated with it – it only acts as the HTML container. In fact this page could have been a .HTM page. The server side logic is handled via the ChatService.asmx page which talks to a business object to read and write messages to the database. The logic there isn't rocket science obviously – most of the methods actually return small HTML fragments to minimize the work that needs to be done on the client – the client picks up the Web Service result and simply assigns the snippets into the appropriate tags on the page. HTML is a great way to pass data back as long as data is not too large. In this case the data is things like the new messages, the User List with Activity status, and the drop down list of active chats. All of these are small result sets that get returned and can easily passed back from the server as HTML. In that respect the Web Service is not a pure DataService, but it becomes part of the UI layer as well (like a typical ASPX page).

The end result in all of this is that this sample has surprisingly little code and I managed to get all of this to run on one short battery charge on my flight home <g>, which isn't bad at all.

But remember that building applications like this, that require client and server side logic are essentially distributed applications and regardless of which technology you use to debug this stuff it will take significantly longer than the equivalent server only technology. It also requires more discipline than standard ASP.NET pages because you have to make sure your service code on the server works before you can even think about trying to call this stuff from the client. Debugging too – even server side – is much more challenging. IN this scenario for example I have to deal with timers firing requests every 5 seconds. Have you ever tried to debug ASP.NET or Web Service requests with multiple incoming hits? <g> So you get to turn off the timers and then set up your client code and debug one hit at a time, and then when that works turn on the timers again. This sounds pretty obvious now as I write this but while you're in the middle of a debug cycle there are a lot of parts in the air to remember and keep track of. It's doable but as with anything – it takes some time getting used to and find the common development patterns that occur over and over again. The same sort of issues popped up with the Progress Bar/Long Running Request sample also posted with the samples.

Anyway – that's a lot of talk about something fairly straight forward. Go check it out and poke around. I'm sure somebody will break it <g>…

The code for all the samples can be found here:

www.west-wind.com/presentations/introtoajax/introtoajax.zip