Bluish Coder

Seaside for Dolphin Smalltalk Coming Soon

According to Avi Bryant on the Seaside mailing list, a 'useful version of Seaside' will be available on Dolphin Smalltalk by the 25th of May.

I haven't forgotten, I'm just slightly behind schedule (so what else is new... sigh). But there's nothing like a public commitment to make things happen, so: I promise that I will release some useful version of Seaside on Dolphin by this time next week - on or before Thursday, May 25.

No Continuations for the JVM

Gilad Bracha writes that the JVM shouldn't get continuation support and gives some thoughts to continuation based web servers as well.

Summary: In the short term, continuation based web servers are very nice. Seaside is the nicest one I've seen. But ultimately they are just a phase, and we can already see how we will outgrow that phase. Since continuation-based servers won't be all that significant in the long term, and given the huge lead times and costs of adding continuations to the JVM, it makes little sense to support them.

In a recent post by Avi, author of Seaside, to the Seaside mailing list, he comments that DabbleDB (which is written in Seaside) actually makes very little use of the continuation based elements of the framework:

As a data point, it's certainly interesting to note that Dabble DB makes very little use of call/answer - the only major uses are when importing and when processing payments. We were intentionally going for a very modeless UI style, so this shouldn't be too surprising. The question is whether this kind of modeless web app will become more common... it seems like it probably will. If so, then yes, the continuation aspects of Seaside will become less interesting, and the callback aspects will become more interesting...

I've found similar in web applications I've been writing lately. Less use of the return from the continuation but making heavy use of the ability to register functions to be called on button clicks, etc (the callback aspect). But when you need the use of the continuation returning for workflow it's very very useful to have it.

Google Web Toolkit

This is pretty nifty. Google have released 'Google Web Toolkit'. It's a system for writing ajax applications in Java.

The Java code is compiled into Javascript which then runs in the browser. From the Google site:

GWT applications can be run in two modes: * Hosted mode - In hosted mode, your application is run as Java bytecode within the Java Virtual Machine (JVM). You will typically spend most of your development time in hosted mode because running in the JVM means you can take advantage of Java's debugging facilities and remain within an IDE like Eclipse. * Web mode - In web mode, your application is run as pure JavaScript and HTML, compiled from your original Java source code with the GWT Java-to-JavaScript compiler. When you deploy your GWT applications to production, you deploy this JavaScript and HTML to your web servers, so end users will only see the web mode version of your application.

Dojo and Spidermonkey

I attended the sessions on Dojo at the Ajax Experience conference to learn a bit about it.

Previously I'd considered Dojo to be a large, hard to understand library but I came away quite impressed with it after attending the seminars related to it. You can use the included package mechanism to make the base package fairly small and have components automatically loaded when required. One other neat factor is that Dojo can be used in a server side or command line Javascript environment.

I used Spidermonkey, the Mozilla C based implementation of Javascript, to try it out. I downloaded a nightly tarball of Dojo to get the source so I could set up a customised Dojo build for Spidermonkey.

Dojo has a 'profile' system that allows you to create a customised 'dojo.js' which contains Dojo packages that you want preloaded. Anything not preloaded will be loaded automatically when required by the package system. One file that is needed by Dojo is 'hostenv' which needs to be tailored for a specific Javascript implementation. There is a hostenv_browser for web browsers, hotenv_spidermonkey for spidermonkey, hostenv_rhino, etc.

To set up a customised dojo.js, which does nothing but makes it specific for Spidermonkey, I created a 'buildscripts/profiles/spidermonkey.profile.js' file with the following contents:

var hostenvType="spidermonkey";
var dependencies=[];
load("getDependencyList.js");

This is exactly the same as the 'minimal.profile.js' but with the hostenvType set to 'spidermonkey'. Once this is done a customised dojo.js system for Spidermonkey can be created with the following Ant command:

cd buildscripts
ant -Dprofile=spidermonkey -Ddocless=true release intern-strings

The custom Dojo build for Spidermonkey is created at 'release/dojo'. You can test it with Spidermonkey with something like:

cd release/dojo
js
js> load("dojo.js");
js> dojo.version
0.2.2+ (3802)

Many of Dojo's libraries are usable from Spidermonkey, including the package system and events. Here's an example demonstrating a usage of Dojo events from Spidermonkey:

cd release/dojo
js
js> load("dojo.js");
js> dojo.require("dojo.event.*");
js> var scheme = {}
js> scheme.jit = false
false
js> scheme.setJit = function(value) { this.jit = value }
js> var monitor = {}
js> monitor.watchJit = function() { print("Jit: " + scheme.jit) }
js> dojo.event.connect(scheme,"setJit",monitor,"watchJit")
[object Object]
js> scheme.setJit(true)
Jit: true
js> scheme.setJit(false)
Jit: false

The intent of this is to test decoupling some of the 'Scheme in Javascript' code from the browser DOM so it can be run from the command line. I don't want the code to explicitly check DOM objects so instead it keeps internal variables and browser specific code can watch these for changes to set checkboxes on the page.

In this case I use 'dojo.event.connect' so that when 'setJit' is called then 'watchJit' is called afterwards. As can be seen from above this works.

Melbourne Bound

The Ajax Experience conference has been very interesting so far. Lots of great talks and technologies. I'll post more on that later when I get some free moments.

The plan after that was for me to fly back to NZ on Saturday night, arriving in Auckland on Monday morning, then from there back to Wellington.

Unfortunately I now need to go to Melbourne for work reasons so I get to arrive in Auckland after a 12 hour flight, hop on a 3 hour flight to Melbourne almost straight away, arriving there Monday morning and jumping straight into work. After 15 hours of flying I'm not sure how productive I'm going to be! Hopefully I'll only be there for a week at most and I can finally get home and play around with some of the new technologies I've been hearing about at the conference. And finish off some of my own projects.