Seaside: A Webapp Framework for Smalltalk

by Jeremy Chan

The sheer abundance of web application frameworks out there is the tipoff that HTTP is a woefully inadequate protocol for building complex web applications.

Everyone is trying to find just the right mix of interoperating components, languages, and standards to make this somewhat more bearable. Seaside, developed by Avi Bryant and the Seaside community, is yet another web application framework (YAWAF?). It is squarely aimed at all web application developers, but will likely have the biggest impact with the population of object-toting Smalltalkers who still seem to be lurking about (Note: The author is one). Avi Bryant presented Seaside to a room of about 50 attendees at the Smalltalk Solutions Conference, held in conjunction with the LinuxWorld and NetworkWorld Conference & Expo in Toronto.

According to the website, "Seaside provides a layered set of abstractions over HTTP and HTML that let you build highly interactive web applications quickly, reusably and maintainably". Seaside's prime directive is that the framework should isolate developers from the tedium of link and state management, and baked-in control flow. Seaside also shuns the hand-coding of HTML and indeed any templating whatsoever, opting instead for a component-based approach in which objects know how to render themselves into HTML. Every piece of UI in Seaside is modelled by a "WAComponent". Each component has a "renderContentOn:" method, which allows it to render itself onto the canvas. In the listings below, the object named "html" can be thought of the "canvas"-like component (or page), to which messages are sent to render html content. For example:

   "links"
      html anchor
         callback:[self doSomething]
             text: 'Link text'
    "checkbox"
        html checkbox
          submitOnClick;
          value:someValue;
          callback:[:v | self setSomeValue: v]
    "styled text"
         html span class: aListItem cssClass with: 'some text';

The idea is that each page is composed by a tree of tiny renderers, each of which manages a bit of state and has a bit of rendering capability. Even for someone unfamiliar with the Smalltalk language, the code above is not too difficult to understand. Of note in the "link" example, the HREF attribute need not be invented and specified by the developer -- it is handily generated by the framework. A Smalltalk block is simply supplied to tell the app what to do when the link is clicked.

A questions arises, though, as to whether it is a good idea to generate all page elements with component renderers, or whether document markup is sufficient or even better in some cases. For example--a dynamic list of items, rendered on the server in Seaside might look like this:

   "unordered list"
       html undorderList:
          [list items do:
             [:ea | html listItem: 
                [self renderItem:ea on:html]]]

Is this easier to write/understand than something like:

	<ul>
	< % for(List item: items) {%>
		<li><% self.renderItem() %>
	<%}%>
	</ul>?

that you might see in a traditional web app page template?

I suppose it depends on how your brain works. To an object junkie, the internal consistency of syntax of the Seaside version is pure nirvana. To a page designer, it might be a bit of an unnecessary mental contortion. (aside: the Seaside version might afford the ability to later replace the renderers for non-broswer clients).

One rule of thumb is that we should aim to model declarative things in a declarative languages (XML, HTML) and procedural things in procedural languages (Java, Smalltalk, etc). The popularity of XML has given rise to its (mis)use in various context to model branching, looping, exception handling, and other procedural logic. Similarly, since at least parts of an HTML page are inherently declarative, it might be best to directly type in the declarations. This isn't more apparent than in the contortion required to add a space on your html page. In a Seaside app, you have to send the "space" message to the "html" object. Sigh.

The rule of thumb isn't hard and fast, though. Avi contends that app developers own the structure of the data on the page (even if that structure happens to be rendered on the page using HTML markup) and should be responsible for managing it. The list of items in the example above may indeed not even be rendered as a list once styles are applied--it could, for example, represent a menu of items - the generation and management of which is outside of the bounds of a page designer. The designer would, however, style the list to look like a menu. This separation of concerns is very clear within a Seaside application. I'd like to see an extra layer of abstraction, however, that provides components with methods like "menu" rather than "unorderedList" for cases like this, though.

The other problem with decomposing a user interface into small consituent rendering components is that debugging tends to be more difficult in some ways--it may not be very clear about how one discovers what pieces of an interface relate to the pieces of code that generates that interface if one didn't write that code in the first place. In traditional web-apps, one can simply look at the template to understand the structure of the page. To address this, the Seaside team quickly showed a web-based meta-browser tool that allowed the user to more easily view the tree of component renderers. Links from stack trace error pages, for example, take you directly to the line of code in the running environment, and allow you to make modifications in the running image.

Of course, there are upsides to the Seaside approach: the developer is largely freed from managing control flow state, form submission logic, and all those pesky URLs that make it difficult to change (and regression test!) a web app once it has been built. Seaside seems like it would allow rapid prototyping and reconfiguration of user interfaces by reconfiguring component renderers in novel ways without having to worry about state and link management headaches.

A interesting component of Seaside is its AJAX integration. Seaside has a set of Smalltalk packages and classes that provide a way to both control/invoke components of the scriptaculous javascript library, and which allow the developer to easily hook up handlers to scriptaculous AJAX requests. No knowledge of Javascript or AJAX constructs is required. Responses to AJAX requests are snippets of html generated by various Seaside rendering components.

Seaside is a bit on the bleeding edge for Smalltalk webapp development. The presenters were clear on the fact that code in the framework is very young, but it seemed to have a small, interested following even at this stage. Alignment with Smalltalk definitely provides some big wins, not the least of which is that there is no visible compilation step when code is altered, and that you never have to "deploy" code or restart the server to test your changes in the development environment, which is simply a Smalltalk image. The presenters almost seemed to take this for granted, but the beauty of the Smalltalk environment does that to you after a short time spent in it.

Jeremy Chan is a Principal Consultant at the Jonah Group and a Technical Architect with over 10 years of experience in object-oriented software engineering.

Posted by Jeremy Chan at 06:04 PM  Permalink

This is a public forum. CMP Media and its affiliates are not responsible for and do not control what is posted herein. CMP Media makes no warranties or guarantees concerning any advice dispensed by its staff members or readers.

Community standards in this comment area do not permit hate language, excessive profanity, or other patently offensive language. Please be aware that all information posted to this comment area becomes the property of CMP Media LLC and may be edited and republished in print or electronic format as outlined in CMP Media's Terms of Service.

Important Note: This comment area is NOT intended for commercial messages or solicitations of business.