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

[Ramon Leon]

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