The Smalltalk Industry Council's Coding Contest was very interesting. I participated in it. We had 48 hours to build a Survey web application that took survey answers from participants and then reported on those answers.

The idea was to build the application in Smalltalk, throw in as many bells and whistles as you could and see how you went against the other competitors. We'll find out who's in the top three at the start of next month - two weeks time.

I wrote my application in VisualWorks 7.3 using VisualWave as the Http Server base - then on top of that I used SimpleWeb.

SimpleWeb? I hear you say. Yes, SimpleWeb. SimpleWeb is basically a re-write of a framework I have at Wizard Information Services. At Wizard we use VisualAge. Because we use VisualAge we cannot use Seaside - it requires continuations.

What we wanted was something as simple to use to build web applications as seaside, yet without continuations. Thus was born our Web Canvas framework which uses Server Smalltalk underneath for it's Http Server. The API to build web applications is very simple, inspired by Seaside.

I so liked our answer that we had, I decided to re-write it for this competition during the 48-hours of the competition to use instead of Seaside. Why would I do such a thing? - mostly because of debugging. With Seaside, you have continuations. With continuations you have the worst debugging experience you could ever possibly imagine. The VisualWorks debugger does not like processes to suddenly disappear and be replaced with an entire new continuation stack.

SimpleWeb uses callback's which hold on to BlockClosure's. Each time a page request comes in, the document ree with it's BlockClosure's is duplicated so that you have a new unique instance for the BlockClosure's callbacks to run on. In this way you get the same sorts of behaviour you have in Seaside, yet without continuations.

On top of this I built my submission. I also used Prevayler - the one I made, not the Java one - as the persistence mechanism. Hey Janko Mivsek! It works! - Just like we designed it too. Unlike regular Prevayler, this Prevayler is completely transparent to the developer - you don't explicitly write and read things from a log. In fact, it doesn't use one log, it uses lots of little BOSS files for persistence.

So, combining a nice persistence mechanism with a nice web framework, I was able to rapidly knock together my submission for the competition. I'm pretty pleased with my domain model and I had lots of tests to go with it - 90 of them. I didn't do any view tests, that's always really hard and I knew it would be too big a distraction at this point.

Some of the things that distinguish my Survey application from the requirements of the competition: You can have multiple survey's in the system, you never 'drop' them and start a new one. Only one Survey is active at a time. You can view past survey results, there's an RSS feed for them and there's an XML link at the bottom of each Survey results page to get an export.

So because Blaine Buxton has put up his code, I thought I might do the same so that we can see how each other has gone. I found his approach to the problem interesting and I'm now more convinced than ever that Smalltalk is a brilliant platform for making Web Applications -of any kind-.

Here's the link to my submission. Simply load up the Survey.pcl in to your copy of VisualWorks 7.3 and read the workspace that pops up. It tells you how to start it and use it.

One thing that Blaine got to do that I didn't end up doing was an editor for survey's. That's a neat idea and it turns out to be fairly simple to implement. I just gave admin's a text area to paste in that weird format that the competition requires.