[Seaside] Seaside subsets

[Göran Krampe]

Hi Avi!

Let me comment from my experience developing Gjallar.

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

Same with me. The canvas style is very nice. Giovanni Corriga is actually
trying to mimic it in HttpView now.

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

We neither. Honestly I haven't even a good clue about what it is. :)

> - 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 inform: here or there. And yes, we also have several of our own
components we reuse within the app. And we actually have a subclass of
WACanvas for some added bits. But I don't think we use much standard
widgets, well, we do use WABatchedList - and a special version that can
deal with an "unknown" number of items.

> - 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 don't use them. But I might learn to use them :).

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

Don't use that. But I would gladly like an introduction covering it
because I don't think I have seen one.

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

Interesting. We use libraries, but we have seen some issues with slow
loading. Perhaps we should do it like you do.

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

Never used it.

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

Only use it a little. But that might primarily be because I haven't really
"adopted" that style.

> - 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 don't use any of that, well, perhaps somewhere - but honestly - I am
not sure how to use it and we haven't bothered yet to "back"-button-proof
Gjallar.

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

Same here. No effects yet. AFAIK we only use the completion thingy so far.

> 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

One thing we have done is to keep track of parent components with an added
instvar. We have our own WAComponent subclass. We only use it sparingly
and perhaps we could move away from it by using some other kind of
component coordination - like for example piggybacking on the session or
something.

regards, Göran