[Seaside] Seaside Widgets & SqueakMap example

[Avi Bryant]

On May 20, 2004, at 3:45 PM, Yanni Chiu wrote:

> I'm thinking of calling it SSW, for Seaside Widgets.
> The reason it got built is that I found it tedious
> to code the Seaside pages. Right now, it's probably
> harder to code the widgets, but I was hoping to
> be able to use GUI building tools like those for
> wxWidgets, which can emit XML files. Then the SSW
> page could be generated from the XML.

Yeah, that's an interesting idea.  I've always found the balance in 
Seaside between the imperative, stream-based renderer and the stateful 
component trees to be a tricky one: what wants to be a method and what 
wants to be an object?  So it's always enlightening to look at other 
points on that spectrum.

Looking at your examples, I agree that (for me, anyway), building the 
widget trees is more tedious and less clear than using the renderer 
directly, but it's clear that it would support a UI builder fairly 
easily.  One thing to look at might be to do a web-based builder, maybe 
extending the halo system that's already there.  As well as XML 
formats, you might think about an approach more like Apple's .nib, 
where the actual widgets are just manipulated live and then serialized 
to a binary stream.  Any references to model objects are replaced with 
proxies, and these are hooked up to appropriate models when you load 
the UI back in.

Because of the way models seem to propagate down your tree, I think it 
would be very valuable to do the UI building with a live example of the 
model in place, so that you can easily show which selectors are 
available to be hooked up at each level and so on.

The one thing I especially miss about the renderer in such models is 
the ease with which you can do iteration and conditional logic.  It's 
just so much nicer to use real Smalltalk control structures than to 
have an IterationNode or ConditionalTag or whatever, as you usually get 
in template or widget-tree systems.  I haven't yet come up with a good 
way of unifying those two approaches, however.

Avi