[Seaside] Application context
pat.maddox at gmail.com
Sun May 17 22:23:21 UTC 2009
Thanks for the reply. Comments inline
On Sun, May 17, 2009 at 2:32 PM, James Foster <Smalltalk at jgfoster.net> wrote:
> Hi Pat,
> As I understand it you want application data to be separated based on entry
> points, but otherwise share the same environment (e.g., deployment image).
Well my real goal is to have a single place where I wire up my app's
major dependencies - repositories, connections to external services,
etc. This is partly so I can do multiple installs, but mostly for
ease of use.
> 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.
This makes sense to me but I'm not sure how to make it work. If I
have a class instance variable, then each subclass gets its own
version of that variable. The whole point of this is to share one
object throughout all components in an application.
> 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:').
I still need to know where to put this Dictionary though. I take it
that a class variable in my WAComponent subclass is not such a bad
idea after all?
> 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 machines
Yes I certainly need to figure out how I want to deploy this stuff.
That kind of strategy would work really well for this particular app.
But I'm also interested in "out of the box" (and cool! (and pricey ;))
behavior with gemstone.
> James Foster
> 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
> seaside mailing list
> seaside at lists.squeakfoundation.org
More information about the seaside