[Seaside] Seaside subsets

Yann Monclair yann at monclair.info
Wed Feb 14 13:24:11 UTC 2007


I answered to Avi and not to the list. Weird horde not respecting the reply-to

I have mainly used Seaside to build my online calendar SummerTime. It is the
only "big" web application I have been involved with(infact the only webapp).

I use the #call: (or the #lightbox:) only to call another component (the
and then switch back to the main page again. I use the ajax in Scriptaculous,
but not really the Scriptaculous effects.

I use libraries for my css, but I think externalising the css could be a plus,
to make it editable to someone not using squeak.

I think ajax has changed the way to see webapps, and we don't want to have to
chage the page anymore, but just to update a part of it. I do that a lot in my
application (maybe too much , when I see the slowness of my calendar :( ).



Quoting 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 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
> prototyping.
> - 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).
> - 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 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.
> - 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.
> - 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
> NavigationContext.
> - We do use Scriptaculous, but mostly only the Ajax bits rather than
> the effects.
> 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
> _______________________________________________
> Seaside mailing list
> Seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

More information about the Seaside mailing list