[Seaside] Two Approaches to Getting Started. Which One Should
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