[Seaside] Seaside subsets

[Lukas Renggli]

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

Yep, using it already yields a deprecation message in the 2.7 version
of Seaside.

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

Magritte makes heavy use of decorations, e.g. if you tell a
description to generate an editor it answers an instance of a generic
component. Validation, buttons, title, help-text, ... is added with
decorations that can be customized to your needs and your specific
application. Of course this could also be done differently, but I
think it's nice to have.

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

No, but beginners seem to like them to learn from.

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

Yes, that's a pity. A redesign using CSS2 outlines and tooltips could
maybe help. Another problem is toolbar at the bottom, it sometimes
needs special care for the CSS design.

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

I use them in Pier, but I guess most people don't know how to use them.

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

Yep, except for tutorials and teaching Seaside I find this component useless ;-)

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

Ajax, auto-completion and drag&drop are the parts of the library that
I am using mostly right now. However getting really serious about
those things usually requires to rewriting (extending, modifying) big
parts of the JavaScript code to exactly fit the specific needs.

Personally I find the JavaScript part of Scriptaculous quite bloated
and difficult to extend and understand. In my opinion a slim (and
better packaged) library like MooTools (http://mootools.net) would fit
Seaside much better.

> One problem we face from time to time is cross component message
> passing. If you have an event in an "inner" component but want to
> change something in an "outer" component (yeah this is bad coupling
> and stuff but still happens). In one application we have explicit
> parent links but that turned out quite horrible, I am against this
> practice. I have once done an experiment to directly support dynamic
> variables but never pursued it any further. It might be worth to have
> a second look at it.

Philippe: I use announcements to do that. This does not only work from
child to parent, but also the other way round (and from session to
components, session to session, and more). Moreover it does not
violate coupling. After all you talked about events ... an
announcement is a synonym for an event.

Some additional points to the list of Avi:

- I don't know of any usage of the code in the category
Seaside-Components-Frames. I guess this code dates back to the very
first versions of Seaside 2.0 that used some strange technique to
display children ...

- Continuation should go to the base image ;-)

- I never used WACachedDocument, either Apache or a file-library
should do the trick.

Cheers,
Lukas

-- 
Lukas Renggli
http://www.lukas-renggli.ch