[Seaside] Seaside subsets

[Ramon Leon]

>From building reservetravel.com/v6 as well as a few internal and prototype
applications, here's my take...

> Of Avi Bryant
> Subject: [Seaside] Seaside subsets
> 
> - 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 use Magritte, which uses them heavily, and I often use addMessage: to wrap
a Magritte generated component with a title, beyond that, I never use them.

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

Ditto, however, I use them as samples, often copying the class and modifying
heavily to get an app specific custom version of something I need.  Paging
in reservetravel.com/v6 is done with a subclass of WABatchedList that works
over a web service passing the necessary state for the needed page.

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

Ditto.

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

Ditto.

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

> - 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 like WATask, I like having an abstraction for coordinating UI workflow,
and I like that it lets me do things I can't do in other frameworks.  I use
it sparingly, but when I need it, I need 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.

I use them a lot with Magritte, though the call stack rarely gets deep, and
I do the currentChild thing as well.  

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

When possible I just stay on one page and use Scriptaculous to update parts
of it, and lots of Ajax updating and requesting, though little if any of the
effects.  I think the effects are cheesy.  But the updater has completely
changed how I view web apps

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

Seems from the other posts and mine, your experiences are mostly typical.
I'm curious, as the original author of the framework, what might you have
done differently knowing what you know now?

Ramon Leon
http://onsmalltalk.com