[Seaside] Application context
Smalltalk at JGFoster.net
Sun May 17 21:32:28 UTC 2009
As I understand it you want application data to be separated based on
entry points, but otherwise share the same environment (e.g.,
If you will have a small number of pre-defined entry points, then you
could have separate components for each entry point and subclass from
a common ancestor so that they share behavior. With this approach you
could define a 'class instance variable' in the abstract superclass
and then each subclass would have its own data.
Alternatively, you could use the entry point as a key in a Dictionary
containing various different application data sets. You can get the
entry point from 'self session baseUrl printString' or 'self session
baseUrl path last'. With this approach you can keep your class
variable, but make it a Dictionary and do similar lazy initialization
of the Dictionary and of the contents (using #'at:ifAbsentPut:').
Also, depending on your deployment strategy, you could use multiple
Smalltalk images. This "horizontal scaling" is a simplification of the
approach taken by DabbleDB and allows hundreds of thousands of
applications with the same code but different data and uses multiple
On May 17, 2009, at 1:49 PM, Pat Maddox wrote:
> Where's a good place for me to do one-time setup and then make certain
> objects available to the rest of the application? I created a
> UserRepository that I want each of the components to use. So far I've
> created a base subclass of WAComponent, it has a class variable named
> TheUserRepository. I have a class-side method which lazily
> instantiates it. Then the instance initialize for each of my
> components points an instance variable at this method. The code looks
> "ANComponent userRepository"
> TheUserRepository ifNil: [TheUserRepository := GDRepository for:
> ^ TheUserRepository
> super initialize.
> userRepository := ANComponent userRepository.
> All of my components inherit from ANComponent so they each have the
> userRepository set when they're instantiated.
> Is this a good way of doing it? It seems to be working so far. I
> don't know enough about seaside to know better at this point :)
> If possible, I'd like to move away from using a class variable to
> store the repo. As it is, I can't deploy the same app twice at
> different entry points because they'll use the same userRepository
> object. So what I'd really like is an Application object that gets
> run once, where I can do all my setup. But that application object
> should be new for each deployment, so that I'm not mixing the data
> between deployments.
> Thanks for any help.
> seaside mailing list
> seaside at lists.squeakfoundation.org
More information about the seaside