[Seaside] Seaside subsets

[Germán Arduino]

Hi Avi, Göran:

Avi, undoubtedly your notes are of high interest, mainly because
DabbleDB must be the largest Seaside production system in the world.

My experience is obviously with more little applications being my real
estate solution the more widely used of my own developments with
Squeak / Seaside, but not near the use nor the complexity of DabbleDB,
of course.

Taking in account the previous comments I can say:



2007/2/14, Göran Krampe <goran at krampe.se>:
> Hi Avi!
>
> Let me comment from my experience developing Gjallar.
>
> > 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.
>
> Same with me. The canvas style is very nice. Giovanni Corriga is actually
> trying to mimic it in HttpView now.
>

I'm also using only Canvas to render.

> > - We never use decorations, ever.  No new subclasses of WADecoration,
> > no #isolate:, no #authenticateWith:during:,etc.  Hasn't come up.
>
> We neither. Honestly I haven't even a good clue about what it is. :)

Exactly same here :).

>
> > - 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 inform: here or there. And yes, we also have several of our own
> components we reuse within the app. And we actually have a subclass of
> WACanvas for some added bits. But I don't think we use much standard
> widgets, well, we do use WABatchedList - and a special version that can
> deal with an "unknown" number of items.
>

I use also inform:  and WABatchedList, but I'm using also Mewa that
provides some widgets.


> > - 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 don't use them. But I might learn to use them :).
>

Same here.

> > - 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.
>
> Don't use that. But I would gladly like an introduction covering it
> because I don't think I have seen one.
>

Same here.


> > - 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.
>
> Interesting. We use libraries, but we have seen some issues with slow
> loading. Perhaps we should do it like you do.
>

Well, only in my real estate app (not in others) I'm using
ShoreComponents, that use  libraries and I'm experiencing also slow
loading. I'm thinking in abandon Shore because the slow loading,
mainly in a shared server. But I don't use my own libraries nor know
much about libraries use.

> > - 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.
>
> Never used it.
>

Starting some tests about how to use it to a new system. But not in
use in my current products.

> > - 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.
>
> Only use it a little. But that might primarily be because I haven't really
> "adopted" that style.
>

I use a lot #call: and #answer:. Must investigate how to use/implement
the comments from Avi.

> > - 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 don't use any of that, well, perhaps somewhere - but honestly - I am
> not sure how to use it and we haven't bothered yet to "back"-button-proof
> Gjallar.
>

Same here.


> > - We do use Scriptaculous, but mostly only the Ajax bits rather than
> > the effects.
>
> Same here. No effects yet. AFAIK we only use the completion thingy so far.
>

I'm planning start using Scriptaculous, made some test mainly with
edit-in-place feature, but need to learn a lot.

> > 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
>
> One thing we have done is to keep track of parent components with an added
> instvar. We have our own WAComponent subclass. We only use it sparingly
> and perhaps we could move away from it by using some other kind of
> component coordination - like for example piggybacking on the session or
> something.
>
> regards, Göran
>


Göran: Seems we must go to the same school to learn the same things,
as decorators, halos, preferences, backtracking :D.

Cheers.

-- 
Germán S. Arduino
http://www.arsol.biz
http://www.arsol.net