On Smalltalk

Seaside, unlike most frameworks, has no concept of page templates. This may at first seem daunting, but this is one of its greatest strengths; you will soon learn to love it.

HTML templates suffer from many problems, chief among them a total lack of abstraction and ability to reuse common pieces of HTML within a page without simply copying it. Many frameworks offer some form of user control in an attempt to remedy this, but these invariable fail or become hard to use cleanly because of limitation in the host frameworks ability to wire, coordinate, and maintain state of this component tree, while keeping the HTML in sync with the latest changes made by a designer.

Templates mislead designers into thinking HTML is for presentation, rather than structure to be marked up and lain out using CSS. Putting HTML squarely in the hands of programmers, forces a better separation between developer and designer, between functionality and beauty.

The WARenderCanvas is the class within the Seaside framework which contains a domain specific dialect of Smalltalk allowing the programmer to express HTML directly in native Smalltalk code, seamlessly blending the generation of the HTML with ordinary Smalltalk code, giving the developer the full abstraction capabilities of Smalltalk.

The developer can now freely break up large chunks of HTML into smaller, more general, reusable, and manageable chunks, and take advantage of Smalltalk's amazing development environment to do so.

To create a page in Seaside, one simply subclasses WAComponent and writes a renderContentOn: method like so...

renderContentOn: html
    html text: 'Hello World'

html, is an instance of the Canvas Renderer. In the spirit of learning by doing, let's play around a bit and enhance this example.

renderContentOn: html
    html div: 'Hello World'

renders <div>Hello world</div> and

renderContentOn: html
    html div class: #title; with: 'Hello World'

renders <div class="title">Hello world</div> and

renderContentOn: html
    html div
         class: #title;
         with: [html span: 'Hello World']

renders <div class="title"><span>Hello world</span></div>

From these few examples, the basic pattern of the rendering canvas should be clear. The canvas contains a factory method for creating HTML tags, tags can be sent messages to set their attributes, which usually translate directly to their counterpart HTML attributes.

Smalltalkers dislike abbreviations so where appropriate, some attributes or tag names are expanded into full words, such as "anchor" rather than simply "a". I have yet to see any such changes I didn't fully agree with.

There is one special method in the canvas API, this is the with: method. This method must be the last method sent to a tag, for it contains the contents of the tag, calling it will stop the tag from accepting any further attributes. Using Smalltalk's blocks "[]", cascade operator ";", and tag objects, you can fully express any HTML tag.

I lied, there are two special methods in the canvas API, text: is a synonym for with: on the anchor tag.

renderContentOn: html
    html div
         class: #title;
         with: [html anchor
                     callback:[Smalltalk beep];
                     text: 'Hello World']

callback: is the message you will enjoy the most when working in Seaside. This message is central to the magic of Seaside, and the key thing that makes programming in Seaside vastly different from programming in any other framework.

By sending a block of code to callback: on the anchor tag, I've attached that code as the action to be taken when the anchor is clicked, without thinking about state, or embedding any special tokens into a special URL.

While some frameworks have event systems that allow similar code, few do it with closures that capture state from their local environment, and don't lose state between postbacks of the web page between user clicks. This allows Seaside programming to be very similar to traditional desktop programming, without all the hassles of state management the web introduced.

No more embedding parameters into URL's, no more cookies, no more loading necessary state from hidden form elements, or from the database at each post back, just to continue where you left off after the last user action. The URL, cookies, application and session state, are all still available, should you need to use them directly, or accept data posted from other non Seaside applications, but you don't "have" to use them. The bulk of programming in Seaside is done via callbacks, and passing of objects between components via call: and answer:, freeing one to focus on the problem rather than hacking around the framework.

Remember when I said HTML and real code could be mixed seamlessly, try this in your standard web framework.

renderContentOn: html
    10 timesRepeat:[
        html
            heading: Random sentence;
            paragraph: Random paragraph]

which generates 10 paragraphs of random Latin text, each with a random Latin heading. If you build a lot of prototypes, you might find something like this useful, so useful in fact, that you decide to extend seaside to include it as part of the rendering canvas, a common technique in Smalltalk and Seaside. So you generalize this method into

WARenderCanvas>>randomContentSections: aNum
    aNum timesRepeat:[
        self
            heading: Random sentence;
            paragraph: Random paragraph]

either by subclassing the render canvas, or simply adding an extension method to the existing one. Next time you can simply write

renderContentOn: html
    html randomConentSections: 10.

and not have to think about how it was implement, only that it works. In short, Seaside rocks, it's the best web framework out today. There's much talk about Ruby on Rails, but Rails is just today's framework done right, Seaside is tomorrow's framework today!