[Seaside] Seaside subsets

[Philippe Marschall]

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 only use it in legacy applications but they run with old Seaside
versions anyway (updating even when not changing the renderer API is
not that easy).

> - We never use decorations, ever.  No new subclasses of WADecoration,
> no #isolate:, no #authenticateWith:during:,etc.  Hasn't come up.

We use it rarely, mostly Magritte related where it comes in very
handy. It certainly could be implemented with components that have to
be nested as well. One interesting use we have is a "performance
decoration" that does logging and the other are mostly for sutff
around Magritte components like titles, borders and backgrounds.

> - 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 neither, they just don't fit into the layout of any site. We
override #confirm: and #inform: in our component root class.

> - 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).

Same here.

> - 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 have a build system that sets up the whole config stuff.

> - 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.

Same here. But WAFileLibrary is really convenient for Pier and stuff
like Scriptaculous examples and for getting started fast without
setting up an Apache2.

> - 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.

Same here. A problem with WATask is that it doesn't (yet) support back.

> - 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.

We use it quite often for (Magritte) editors and "viewers".

> - 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 use #registerObjectForBacktracking: form time to time but it's rare
(except for widgets like tab-panels and tables and "currentChild"
stuff).

> - We do use Scriptaculous, but mostly only the Ajax bits rather than
> the effects.

Most applications use Ajax very sparsingly (one or two places) but
one uses it very extensively. Lukas is better qualified to answer here.

> 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...

One problem we face from time to time is cross component message
passing. If you have an event in an "inner" component but want to
change something in an "outer" component (yeah this is bad coupling
and stuff but still happens). In one application we have explicit
parent links but that turned out quite horrible, I am against this
practice. I have once done an experiment to directly support dynamic
variables but never pursued it any further. It might be worth to have
a second look at it.

Cheers
Philippe