8.4. Seaside
Seaside is a highly productive web development framework written in Smalltalk.
Avi Bryant initially developed Seaside in Ruby, in a framework called Iowa. Early
Ruby continuations had a few problems, so the original author of Seaside moved to
Smalltalk. Since then, he's been improving the framework and using it to deliver
commercial applications. Seaside has a few defining characteristics:
 Seaside renders HTML programmatically. Most Java frameworks render
HTML with templates. I don't know enough to advocate one method over
another, but it's certainly different, and it works well in Seaside's model.
 Seaside has a model for components. A Seaside component manages user
interface state and renders itself in HTML. Seaside components are highly
reusable, and they let you think in increments smaller than a page.
 Seaside makes it easy to manage a link. You can specify a link with a code
block, so links don't get out of sync. The framework manages them for you.
 Seaside is modal. This is the author's word for a continuation server
ap
proach. Seaside lets you express one web page, or multipage web flows, in
a single method.
 Seaside's debugging is the best I've ever seen. From within the browser, you
can open a web-based Smalltalk browser, complete with code. You can also
inspect the values of all the objects in the application.
Of course, you also get the advantages of using a highly dynamic language. You
get a rapid feedback loop, interactive interpretation as needed, and full access to
Smalltalk's excellent environments. I used the Squeak IDE for examples in this
chapter. Squeak is a dialect of Smalltalk popularized by Disney.
8.4.1. A Little Smalltalk Syntax
Before we get too far, you should know a little Smalltalk syntax. Don't worry. I'm
not saying that Smalltalk is the next great language; I just want you to see the

languages, too. Java's garbage collection, design patterns, and collections all share
Smalltalk's influence. Consider Hibernate's use of message chaining . If a method
doesn't have a return value, it simply returns itself, enabling tighter code like this:
cfg.add("pet.hbm")
.add("vet.hbm")
.add("pet.hbm");
Many ideas from Eclipse have roots in IBM's VisualAge for Java , which first
shared IDE code and a virtual machine with a Smalltalk product. Smalltalk syntax
is wonderfully consistent.
8.4.2. A Seaside Overview
Seaside is a Smalltalk framework and a server. Remember, a continuation server is
different from other web servers, so Seaside must run in its own environment. In
Squeak, you'll left-click on the desktop to give you a menu (called the world
menu). Then, you'll select Open SqueakMap Package Loader. Use it to
install four packages: DynamicBindings, KomServices, KomHttpServer, and
Seaside, in that order. Now, your Smalltalk image has Seaside. To see it, fire up
the server. In Squeak, you'll open a workspace and evaluate:
WAKom startOn: 9090
WAKom is the name of the server. starton: is a method that tells the server to start
on a supplied port, 9090 in this case. In some ways, WAKom is like Tomcat, or
any other web application server. You can configure it by pointing your browser
to:
http://localhost:9090/seaside/config
You'll see Seaside's configuration screen. Some of the items should look familiar
to you. You'll see a list of registered applications, and some configuration options.
Later, it will become clear that Seaside is more than Tomcat in Java.


with: [html bold: cart totalPrice printStringAsCents].
]
Notice that Seaside components have code that generates HTML. Java people don't
tend to like this approach either, but it's very productive in Seaside. The code in
bold generates the table. First, you see the table message passed to the html object.
This will generate table tags around the code block. Next, you'll see a loop that
processes the items in the cart, a spacer row, and a row with the totals.
8.5.2. Complex Control Flows
For this application, the most complex series of windows is the checkout. Think of
how a traditional stateful application would manage the flow of control. Try out
the checkout in the application and see how it works. Add a few pieces of sushi to
your cart and click on Checkout. This piece of SushiNet will walk you through a
few major steps:
 You'll verify the contents of your cart. If you like your order, you can click
"Proceed with checkout." Otherwise, you'll click "Modify my order." So the
user makes a decision, and flow changes based on the user's input.
 You'll specify a shipping address. You can then choose whether to use this
address for your billing address. Again, this decision impacts the flow of the
application. If you don't want to use the same address for shipping and
billing, SushiNet will reuse the component that renders the shipping address
for the billing addresses. Nice.
 You'll enter your credit card information. If it doesn't verify, you'll go back
to the same screen. If it does verify, you'll get a success screen.
 Users can click the Back button at any time. If the user hits the Back button
after his order is submitted, he'll get a message that the page has expired.
So, the flow looks something like Figure 8-4. It's not that complicated. You've got
four decisions, and based on the decisions, you route the user to the appropriate
place.
If you implemented this flow with Java servlets, you'd need to process four or more
independent requests, as in Figure 8-5. Each one would have to first load the

You'll see the code that implements the cart in Figure 8-4:
go
| shipping billing creditCard |
cart _ WAStoreCart new.
self isolate:
[[self fillCart.
self confirmContentsOfCart]
whileFalse].
self isolate:
[shipping <- self getShippingAddress.
billing <- (self useAsBillingAddress: shipping)
ifFalse: [self getBillingAddress]
ifTrue: [shipping].
creditCard <- self getPaymentInfo.
self shipTo: shipping billTo: billing payWith: creditCard].
self displayConfirmation.
8.5.2.2. Tasks
In Seaside, tasks handle business logic. Let's zero in on the code in bold. It handles
everything after the cart verification. The self isolate method takes a code block
and makes sure everything in the block is an atomic operation, or a transaction.
The next line of code is interesting:

[shipping <- self getShippingAddress.
This statement actually presents the getShippingAddress web page to the user, and
puts the resulting address into the shipping address. You can see how the
framework inverts control. Now, instead of the browser being in control, Seaside
lets you direct traffic from the server. The next three lines show a decision:

billing <- (self useAsBillingAddress: shipping)
ifFalse: [self getBillingAddress]