[Seaside] Seaside subsets

[Michel Bany]

Avi, Do you have in mind to break Seaside apart in smaller pieces,
like you did already with SeasideAsync ?
"... we may want to do some major housecleaning... "


I know of five different Seaside VisualWorks projects at customers.
They are all on a fairly recent version of 2.6b1.

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

They mostly use the old WAHtmlRenderer.
Some are 20% Canvas, some are not using Canvas at all.

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

Not used

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

Some have developed their own widgets.
One customer is using the ShoreComponent date selector.

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

Very limited use of the halos.

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

Not used

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

All css and javascript in the image, versioned with Store as part of the
application. Some customers offshore their development. Having
all the resources together with the application in the same bundle
helps a lot.

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

Used a little bit. Reusing the same WATask insures a consistent  
workflow for
different tasks.

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

Not used.

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

Backtracking currently not used. Some customers have disabled the
back button using some javascript, they would like to reenable it
and use backtracking at some point in time.

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

Scriptaculous is not used, although they all would like to use it.
SeasideAsync is used heavily in four projects.

Cheers,
Michel.