RE: Two Approaches to Getting Started. Which One ShouldIDocument?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

RE: Two Approaches to Getting Started. Which One ShouldIDocument?

Blanchard, Todd
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: [hidden email] [mailto:[hidden email]] 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
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside