[Seaside] Application context

[Pat Maddox]

On Sun, May 17, 2009 at 8:35 PM, Ramon Leon <ramon.leon at allresnet.com> wrote:
>>
>> There are a few different ways for objects to get a dependency,
>> looking up a singleton is only one of them.  I'd prefer not to use it.
>>  Let me show you some fake code that should hopefully demonstrate what
>> I want to do better than I've explained it so far.
>>
>> MyBlogApp new userRepository: UserRepository new;
>>    mountAt: '/us/blog';
>>    run.
>>
>> MyBlogApp new userRepository: UserRepository new;
>>    mountAt: '/ca/blog';
>>    run.
>>
>> Each of those is an instance of my blog app, and runs separately from
>> the other.  The userRepository automatically gets injected into the
>> components that make up the application.  This way they can just look
>> up their local instance variable as opposed to grabbing a singleton.
>>
>> Is that clearer?  That's the gist of what I'm trying to do.  Now I
>> just need to know how to do it with Seaside.
>>
>> Pat
>
> Ah, I see, you're wanting to be involved in the creation of the root
> instance of your component and hand in the dependency there.  What you're
> looking for is a custom render loop, subclass WARenderLoopMain so you can
> override #createRoot and control the creation of your component.  Then you
> can pass in any dependencies you like during the construction of your
> component.
>
> You can plug in your render loop during the registration of your app on a
> mount point.
>
> YourRootClass class>>initialize
>     | app |
>     app := self registerAsApplication: 'someAppName'.
>     app preferenceAt: #mainClass put: YourRenderLoop.
>     ^ app

The *real* reason for this question, though I didn't know it at the
time, was that I was asking myself "how am I going to test this?"  So
I wanted to know a way to inject fake repositories in.  I definitely
didn't need to be able to configure it at the root - right now it's a
good assumption that there's only one user repository for my app.

I created a class, ANUserRepository, and then pointed the global var
AccountRepository at a new instance.  I pointed another global
DevAccountRepository at that instance as well.  Now in the setUp
method of my test I set AccountRepository to a fresh instance for
testing purposes, and in tearDown I reset it to DevAccountRepository
so I can still click around in the browser.

Thanks again James & Ramon for your feedback.

Pat