[Seaside] Seaside subsets

[Avi Bryant]

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
prototyping.
- 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.
- We don't use libraries (CSS or Javascript) at all.  We use
#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
NavigationContext.
- 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...

Avi