[Seaside] Two Approaches to Getting Started. Which One Should
ramon.leon at allresnet.com
Mon Jun 12 18:31:46 UTC 2006
> 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.
More information about the Seaside