[Seaside] Seaside subsets

[Boris Popov]

Avi,

Please see below,

-Boris

-- 
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5
http://tinyurl.com/r7uw4

boris at deepcovelabs.com

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is
private and confidential. If you have received it in error, please
notify the sender and delete the entire message including any
attachments.

Thank you.

> -----Original Message-----
> From: seaside-bounces at lists.squeakfoundation.org [mailto:seaside-
> bounces at lists.squeakfoundation.org] On Behalf Of Avi Bryant
> Sent: Wednesday, February 14, 2007 12:47 AM
> To: The Squeak Enterprise Aubergines Server - general discussion.
> Subject: [Seaside] Seaside subsets
> 
> 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.

All Canvas here as well.

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

Single use of it via (self addDecoration: WASessionProtector new) on the
outermost component, no other uses have come up yet, but I haven't
looked at adding application-wide field/form validation and not yet sure
if that's one of the viable approaches.

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

Yup, great to use in presentations, never actually used it here.

> - 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 tend to toggle them to see the component composition when changing
layout elements, but given that application state had solidified many
months ago, I can't recall last time I used them; indeed reason being
that CSS based layout and halos just don't play well together.

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

Haven't used it, but really does seem useful once a good use case comes
up.

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

This is a more interesting one, speaking from experience, they are great
to get going and keep the files as part of the code-base for seamless
version control and integration. So we do use them, but only in
development. Originally all resources exist in files, every time they
change we load them back into the file libraries (slightly modified to
use file-like addressing) and serve from the image during development
(other guys don't even have front web servers on their workstations). In
production, however, the resources get dumped from the image back into
the file system and apache takes over by overriding aliases normally
served by seaside in development, say /images, /css and /other

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

Our login uses WATask and I loved it, looking forward to using it more
as things come up.

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

Navigation here is controlled in a similar fashion by an outer
component, I've replaced most previous uses of call: with modal YUI
dialogs few months ago, although that's not to say I'd want it gone from
the base framework.

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

Same here, although again, that's not to say there are no feasible uses
of it for us yet, I'd rather have it available than not, and so far its
been a killer demo feature, who cares if its rarely ever used in real
systems :)

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

We use Scriptaculous for Ajax as well as effects, plus bits and pieces
of YUI for overlay dialogs and calendar widgets.

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

I'm all for it, as long as we don't remove features that are critical
for those ever-important demos, regardless of how little use they may
see in real life.

Cheers!

-Boris