[Seaside] Seaside subsets

[Rick Flower]

Avi Bryant wrote:
[ ... ]
> - We never use the old WAHtmlRenderer code.  Ok, no surprise there,
> but in case anyone was wondering, it's all Canvas all the way.

Ditto..

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

I've got a WASessionProtector used as part of a decoration and frankly 
I've got no clue what that does for me.. I got it from somewhere else.. 
I might try removing it to see whats missing.. (clueless on that one).. 
Otherwise I'm really not sure what Decorations get you.

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

No widgets here yet and I'm planning on keeping it that way.  I'm using
100% Canvas tags too.

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

I use Halo's once in a while as well to view the pretty printed source 
or to configure my app -- I also find that my pages' css can goof up the 
halo's output, but I can live with that.

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

I'm also using the preferences, though not extensively yet.. It's 
actually pretty cool that I can load my code in from my "Store" 
repository and the WASession is overridden and session timeouts are 
properly set, etc.

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

Ditto.. I was using embedded and #style methods, but have recently 
switched to external files.. Works like a charm!

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

I don't believe I've got any WATask instances, but I've yet to code up 
my payment mechanism so that may change I suppose.

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

None of the #call or #answers either.. I am using a 'currentChild' sort 
of mechanism that I got from Brian Brown here on the list about a year 
ago.. That went a long way towards working the entire menu system I've 
got now.. I can't thank him enough for his insight, etc.

> - Except for a handful of those "currentChild" state variables, we
> don't use WAStateHolder or #registerObjectForBacktracking: at all.

Ditto..

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

I use SeasideAsync and find it works great for my uses -- I don't need 
the extra features and complexity that Scriptaculous gives -- for now 
anyway..