Rick Strahl's Weblog  

Wind, waves, code and everything in between...
.NET • C# • Markdown • WPF • All Things Web
Contact   •   Articles   •   Products   •   Support   •   Advertise
Sponsored by:
West Wind WebSurge - Rest Client and Http Load Testing for Windows

ATLAS Web Service Chat Sample posted

On this page:

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:




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:





The Voices of Reason


Bertrand Le Roy
April 10, 2006

# re: ATLAS Web Service Chat Sample posted

I disagree with your statement that "XmlScript doesn't seem to provide good support for calling raw JavaScript code". Any event can be hooked either with declarative actions or JavaScript handlers, so you can write either:
<setProperty target="foo" property="bar" value="1"/>
<button click="onClick"/>
function onClick(sender, arg) {
foo.bar = 1;

Rick Strahl
April 12, 2006

# re: ATLAS Web Service Chat Sample posted

Bertrand, but does that work for any object? The click is an obvious handler that has call outs to javascript, but let's say you fire an action of a change() event off a listbox a value change on a textbox. I don't think you can fire off into script code from there...

The problem I see is that in mnay situations you have event chaining where one event triggers the next. Maybe I'm missing it but I can't see how to do that cleanly with ATLAS. In the above example, imagine doing:

Timer Refresh that updates the messages label, when the label is updated scroll the containing DIV tag to the bottom. How would you do that with XmlScript?

June 11, 2006

# re: ATLAS Web Service Chat Sample posted


i was trying to run your code, but i can't seem to find where the ScriptCallBacks.BusinessObjects is..

Rick Strahl
June 11, 2006

# re: ATLAS Web Service Chat Sample posted

The bus object code should be in the APP_CODE directory.

July 22, 2006

# re: ATLAS Web Service Chat Sample posted

It is not there... Missing are Westwind.Tools as well..

# DotNetSlackers: ATLAS Web Service Chat Sample posted

# Technical blog: ASP.NET, C#, VB.NET, ADO.NET: april 2006

# Technical blog: ASP.NET, C#, VB.NET, ADO.NET: weekend project, ATLAS chat

January 03, 2007

# re: ATLAS Web Service Chat Sample posted

I was also trying to run your code but the ScriptCallbacks.BusinessObjects is not there in the APP_CODE directory.

January 26, 2007

# re: ATLAS Web Service Chat Sample posted

same thing with me. please help

Jan Bannister
August 04, 2007

# re: ATLAS Web Service Chat Sample posted

I dislike this handholding attitude that pervades the .net world. There seems to be a vast pool of people that think that someone on the internet will bail them out of all their problems.

The example is really simple, just write your own server side implementation... sheesh.

West Wind  © Rick Strahl, West Wind Technologies, 2005 - 2024