[Seaside] Seaside subsets
philippe.marschall at gmail.com
Wed Feb 14 12:37:56 UTC 2007
2007/2/14, Avi Bryant <avi at dabbledb.com>:
> As 2.7 gets closer to beta (right?) and people might be thinking about
> what 2.8 or even 3.0 might look like, I thought it might be
> interesting to share a somewhat surprising experience I've had: Dabble
> DB, which is by far the most complex web application I've ever worked
> on, uses really a rather small subset of Seaside. For example:
> - We never use the old WAHtmlRenderer code. Ok, no surprise there,
> but in case anyone was wondering, it's all Canvas all the way.
> - We never use decorations, ever. No new subclasses of WADecoration,
> no #isolate:, no #authenticateWith:during:,etc. Hasn't come up.
> - We never use any of the standard dialog or widget components. For
> us, anyway, the Canvas tags turn out to be the right level of detail
> for reuse across apps. We do plenty of reusing components within the
> app, but a generic YesOrNoDialog or WATree doesn't cut it except when
> - We do use halos, and I'd like to use them more, but they do badly
> with heavily CSS-styled layouts. Note that I only use them to see
> page structure and for view source, I don't use the web-based system
> browser (that's what the RFB Server is for).
> - We do use the preferences system pretty heavily, with app-specific
> subclasses of WASystemConfiguration that provide defaults we can
> override from /config. But we don't use the baroque multiple
> inheritance system.
> #updateRoot: and #resourceUrl: heavily to bring in external .css and
> .js files which the designer controls.
> - We use WATask sparingly. In fact, pretty much the only use is for
> collecting payment info, which is of course the classic example I
> always give.
> - We certainly do use #call: and #answer:, but much less than you
> might expect given how much talk there is about continuations. And
> the #call: stack rarely gets more than one component deep. Instead,
> we're much more likely to conditionally render a child component, or
> to have a "currentChild" state variable which is constantly modified
> during navigation.
> - Except for a handful of those "currentChild" state variables, we
> don't use WAStateHolder or #registerObjectForBacktracking: at all.
> Well, that's not strictly true: we use it once, with a single
> session-global NavigationContext object that holds all the
> backtrackable state as instance variables. The entire component tree
> at any given time can almost always be determined by examining the
> - We do use Scriptaculous, but mostly only the Ajax bits rather than
> the effects.
> So, I'm curious how typical my experience is. If it's shared by most
> of you, we may want to do some major housecleaning...
An other thing we don't use is the #style method of components. And if
the inspector halo icon would open an inspector in the squeak image
instead of the web that wouldn't hurt either.
More information about the Seaside