[Seaside] Seaside subsets

[Sebastian Sastre]

> -----Mensaje original-----
> De: seaside-bounces at lists.squeakfoundation.org 
> [mailto:seaside-bounces at lists.squeakfoundation.org] En nombre 
> de Avi Bryant
> Enviado el: Miércoles, 14 de Febrero de 2007 06:47
> Para: The Squeak Enterprise Aubergines Server - general discussion.
> Asunto: [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.

I'm using the new canvas. The migration becomes ok when you find all the
equivalent ways to render stuff.

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

I never use decoration nor #isolate: (yet) but I think about that feature
that it could be handly and perhaps I'll be using it soon.

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

I'm using dialogs a lot. I'm developing almos the same as desktop and
dialogs is something we need. I'm using one or two kind of modeled dialogs
wich render a customized frame so you can put there any component to be
rendered but letting the user the clasic cancel ok (#save #rollback)
features. I think this is a must.

> - 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'm also using them a little. They are handy to find a component class and
sometimes to inspect something. 

> - 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 don't needed it yet. Just configuring custom session libraries, etc.

> - 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 haven't go that deep yet.

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

They are a must too. I must admit that I've completely understood them
recently 

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

We rather use them to call the dialogs wich mostly are to edit some object
model.

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

I'm not using effects yet. We found of more value the updater, autocompleter
and the editor.

We use and reuse shore components quite often. 

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

So, here are ours,

Cheers !

Sebastian Sastre

> 
> Avi
> _______________________________________________
> Seaside mailing list
> Seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside