[Seaside] Seaside subsets
michel.bany at gmail.com
Wed Feb 14 16:46:13 UTC 2007
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.
> - 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
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.
> #updateRoot: and #resourceUrl: heavily to bring in external .css and
> .js files which the designer controls.
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
> - 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
Backtracking currently not used. Some customers have disabled the
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.
More information about the Seaside