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

Damien Cassou damien.cassou at laposte.net
Mon Jun 12 17:29:09 UTC 2006

> 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
> Mike Roberts' recipe, in summary, was:
> 1.  Subclass WAComponent
> 2.  Implement the method renderContentOn:
> 3.  Implement canBeRoot on the class side
> 4.  Implement initialize on the class side
> 5.  Initialize the app
> 6.  Point  your browser at the app
> I tried both and was successful using both approaches. Clearly Todd's 
> approach is somewhat more complex, involving as it does three subclass 
> operations. At Step 4 of his procedure, one would have to create the 
> home page component, presumably, using renderContentOn: for that component.
> Mike's approach brings quicker instant gratification but ultimately is 
> one going to have to (or want to) subclass WASession anyway to allow the 
> management of app state? WASession *seems* without a great deal of study 
> to be fairly complicated.
> 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?

I would suggest a mix that allows the user to use the new canvas API 
without subclassing the WASession that is not usefull for everybody.

1. Subclass WAComponent and add #rendererClass to answer the new canvas 
2. Subclass this class for each component you would like on your application
3. Add #canBeRoot on the class side of the main component
4. Visit seaside/config to create the Seaside app

More information about the Seaside mailing list