I walked into the Seaside tutorial halfway through - which isn't bad, as it happens - a goodly proportion of the audience is non-Smalltalkers, so a fair bit of what I missed was an intro. With that out of the way, I'm getting the actual Seaside/Ajax part of the talk. I can't unzip the Scriptaculous library at the moment - I played Civ4 over the weekend, and haven't rebooted yet. Par for the course; the Windows file dialog is hosed.

So - a brief warning about what Ajax is, and how over-use could slam a server, and then it's off to the races. Back after a reboot, and I was able to extract the files. Stupid game :/ So here's a screen shot of the Squeak browser, with a view of one of the callback methods - it's handling one of the asynch calls back from the browser, and rewriting the appropriate pieces:

Some of the scriptaculous code is included in the image as methods (answering strings), and I had a question about that - whether having that be in a separate, loadable file might be easier. On the other hand, using either Squeak or VW, you could just as easily file-in replacements for those methods, as I do for patching this server. The positive of having the javascript in the image is that it's all versionable together. Here's a snapshot of what I'm talking about - one of the javascript methods in support of drag drop inlined as a string:

The funny thing for me is that some of this stuff is oddly familiar. The original VisualWave had bits of javascript support in it, so that you could handle events for widgets (selecting in a list, for instance). Of course, with Wave, the whole form was both submitted and redrawn as a synchronous HTTP POST - but the widget handling issues are much the same.

Side note at this point - all of this Seaside/Scriptaculous integration is available in the VisualWorks port (big hat tip to Cincom's Michel Bany for that).

Question about persistence: there's nothing specific for Seaside, but people use a variety of things. Object dbs (Omnibase, for instance), or GLORP, or a number of other things that are available from vendors and the community.

A question: What about the "classic" approaches? Ruby on Rails is a nice, clean way to approach the old fashioned style of web app - works very well, is very clean. You end up writing a lot of state machine style code in your application though, and it gets harder and harder to maintain. Seaside removes all that overhead from you. So RoR will serve you well if you have a simple "db to web" app to build. If you need to manage state, then Seaside is easier.

You can still work with CSS/templates, they just get integrated right into the Smalltalk image (like the javascript example above). They also support having that loadable from files, of course - DabbleDB does it that way, and their graphics arts people never see a Smalltalk image.

Another question: What about having "clean" URLS? Not easily possible for an entire Seaside application. You can have bookmarkable sections that slam extra stuff in the URL that will deal with that.For instance, DabbleDB is built on Seaside, and does have "clean" urls as entry points.