[Seaside] Two Approaches to Getting Started. Which One ShouldIDocument?

Blanchard, Todd tobl at amazon.com
Mon Jun 12 19:52:30 UTC 2006

You can certainly leave off my first step (custom session) if you don't have state to manage - I always do this out of habit to abstract away the persistent data store.  

The rest is kind of mandatory - you need a base class to specify your renderer (if you want to use canvas renderer), and you need a root/home page component. It's a good idea to have a base class there for sticking common view behavior (like app-wide style info) as well.

-----Original Message-----
From: seaside-bounces at lists.squeakfoundation.org [mailto:seaside-bounces at lists.squeakfoundation.org] On Behalf Of Ramon Leon
Sent: Monday, June 12, 2006 11:32 AM
To: 'The Squeak Enterprise Aubergines Server - general discussion.'
Subject: RE: [Seaside] Two Approaches to Getting Started. Which One ShouldIDocument?

> I got two excellent answers.
> Todd Blanchard's recipe, in summary, was:
> 1.  Subclass WASession so I can manage app state.
> 2.  Subclass WAComponent
> 3.  Add rendererClass method to the WAComponent subclass.
> 4.  Subclass this base component to create the home page component 5.  
> Add a canBeRoot class method to this subclass of the base component 6.  
> Visit seaside/config to create a new Seaside app, choosing session 
> class for sssion and home page class for base component
> So would you suggest I document Mike's, Todd's, or both? What 
> are the advantages of each? Or do you have another way 
> altogether to approach the problem?
> Dan Shafer

I do something similar to Todd's approach...

One time in generic lib that all my apps share
 * Subclass WAComponent (SSComponent), modify default renderer
 * Subclass SSComponent (SSApp), add canBeRoot on class side
 * Subclass WASession (SSSession), added some mods for SSL and a dictionary
in config for application scope hashing, I don't like using the Session
class side because that's image scope not app scope.

Each time I do a seaside app
 * Subclass SSApp for root component
 * Subclass SSComponent for other components
 * Subclass SSSession for app specific session vars
 * Visit seaside/config to create a new Seaside app, choosing session class
for session and home page class for base component.  I don't like the class
initialize approach because it assumes there's only one instance of the app
running, this may not be true.

Seaside mailing list
Seaside at lists.squeakfoundation.org

More information about the Seaside mailing list