A couple of days ago I rebuilt my development image from scratch, and installed Seaside 2.3 instead of 2.21. Within a few more days I expect to have my wife's site (http://www.bountifulbaby.com) entirely converted to Seaside 2.3. A few days before before working with 2.3, I had started the conversion of the site to Seaside 2.21, but fell into old web habits that were not optimal for Seaside, and didn't exploit Seaside as it should. So, I started over, but with 2.3 this time. Here are a few quick notes on what I found:

1. Seaside 2.3 seems to be quite stable.

2. Not surprisingly, some of the API has changed (I suppose in any upgrade this is to be expected). However, due to my own lack of understanding of the Seaside internals, it wasn't immediately apparant what the equivalent 2.3 functionality was. Over the last few days, you can find a number of my posts to this list that illustrate.

3. I find that the simple enhancement of being able to do html bold: 'foo' instead of: html bold: [html text: 'foo'] to be extremely useful. This one enhancement alone makes the switch from 2.21 to 2.3 worth it.

4. The lack of a pretty-printer for the html builder is annoying. To me, this is probably the single biggest downside of moving from 2.21 to 2.3.

5. The way that 2.3 builds a DOM tree rather than directly printing HTML is intriguing. However, from my perspective (building the bountifulbaby.com site), it really doesn't seem to change anything. No apparant advantages, nor apparant disadvantages. From the perspective of my #render... methods, everything seems to be working the same (other than the enhancement stated in #3, above). But, realizing that there is a DOM tree behind the scenes garners a vague suspicion that there ought to be ways to exploit the DOM tree that I haven't thought of yet, and that using a DOM tree is potentially a huge win. I just don't know where the win is, though.

6. Many of the old examples are either completely broken, or partially broken. This will make it harder for new folks to start with 2.3 than if they started with 2.21. For me, this is a downside of 2.3, but a smaller downside than the lack of html pretty-printer is.

7. As I think about how Seaside works, I have a vague suspicion that Seaside is not really suitable for high-volume sites. However, as I say this, let me also add that I think many folks/companies are overly concerned about performance. In my case, my pipe to the internet is *by far* the biggest bottleneck, and I suspect that is true of most other folks/companies. And in any case, I also suspect that Seaside produces a better performing web site than most Java-driven sites have (Java servlets and various Java frameworks-- like Struts, for example-- are not that particularly performant). But, Seaside definitely has a higher back-end overhead than stateless (Smalltalk-driven) approaches have (such as raw Comanche modules, etc.).

8. Most of the bountifulbaby.com site right now is static pages. Seaside produces *no* benefits at all for a purely static web site. Indeed, it even has a rather large downside for purely static sites, by not easily allowing "roundtripping" of page creation from, say, Dreamweaver, to Seaside, and back. And, no, CSS doesn't seem to cut it as a complete designers tool, so losing the "roundtripping" is a huge loss for static-only sites. However, the more dynamic the site, the more advantages Seaside yields. For a completely dynamic site, I think Seaside is unparalleled in it's excellence.

Overall, I am very satisfied with 2.3, and wish to congratulate the Seaside folks for their very fine work, and their very fine help on this list. And, like I mentioned above, there should soon be another public Seaside-driven web site online (at http://www.bountifulbaby.com).

Thanks,

Nevin

Avi Bryant wrote:

Hi all,

I'm putting up a 2.3a snapshot for evaluation at http://beta4.com/seaside2/downloads/Seaside2-3a.st. I made a number of fairly large changes recently, and I've been feeling antsy that they're only available to the (non-existant?) minority of users that track CVS. This code isn't totally complete, but please do try it out.

The changes include:

• HtmlRenderer now builds a DOM tree rather than directly printing HTML to

a stream. This provides a greater amount of flexibility in various places, without (surprisingly) seeming to impact performance. A more minor change (stolen from Cees) is the ability to use either strings of blocks pretty much anywhere, ie,

html bold: 'foo'. html bold: [html text: 'foo'].

• The StateHolder mechanism has been generalized so that any object can be

registered to have the values of its instance variables backtracked. For example, in WABrowser>>model:, you'll see

self session registerObjectForBacktracking: model.

This means that the state of the Browser instance will be snapshotted each time it changes, and using the back button in the web-based browser will have correct behavior.

Component classes that previously used StateHolders for all (or most) of their instance variables can now simply register themselves for backtracking at #initialize time.

Yes, this can eat memory quickly if abused. A "profile memory" link has been added to the toolbar to keep tabs on this.

• The fairly complex Container model has been replaced with a much simpler

notion of delegated components. Each component has a 'delegate' StateHolder. When a component is asked to #call: another component, it stores that component as its delegate. When the #call: returns, 'delegate' will be cleared. When asked to render itself, a component with an active delegate will forward the render request to the delegate. This means that a component will appear to be replaced, in place, by whichever component it calls. This behavior is roughly equivalent to having each child component created with #containerFor: in 2.2.

The "inspect" link now presents a view of the current component tree, showing delegation, so that you can pick which component you want to inspect. This can be useful for understanding the new model.

• The codebase has been massively restructured and more cleanly layered.

Some semi-coherent notes: The "Base" layer consists of Request, Response, and a completely new URL handling mechanism, the WARegistry. This knows nothing about Sessions, but flexibly manages request handlers that map either to static urls or to unique, generated keys. If a unique key exists in the url but there is no active handler for it, the registry will fall back to the closest static handler. The "Session" layer adds continuations and state backtracking. It knows nothing about Components. The "Component" layer includes the delegation and embedding model. For now, it largely shields user code from the changes to the other layers (#registerAsApplication: still works, for example). It also includes all the development and configuration tools. The "Rendering" layer is mostly orthogonal to all of this; it provides the callback scheme and HtmlRenderer.

Known issues:

• The Wiki example is currently broken.
• The new HtmlRenderer does not yet support pretty-printing.
• Usage patterns for Application, Session, and Registry have to be more

fully worked out (where does the current notion of preferences go? Is it still appropiate to subclass Session? etc).

---

Seaside mailing list Seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/seaside