[Seaside] Using Dynamic Bindings in Seaside rendering

[Stephen Pair]

Cees de Groot wrote:

>[a *very* late response, because I only just am catching up with the
>Seaside list]
>
>On Fri, 2003-04-18 at 21:42, Derek Brans wrote:
>  
>
>>Using Dynamic Bindings you can tell all subcomponents of a component to use
>>that component for different things (like #myMainComponent or #myForm)
>>    
>>
>I'm not sure - and sorry for me being so lazy not to look it up - how
>dynamic bindings work, but VW has something called ProcessEnvironment,
>which is a dictionary in a Process instance var (with inheritance
>through parent processes). That's not exactly a dynamic binding but is
>trivial to implement and works fine.
>  
>

DynamicBindings is equally trivial and more correct.  ProcessEnvironment 
is basically where I started with the "Runtime Environments" package, 
which did exactly the same thing.  The problem with storing things in 
the Process is that a context stack and a Process are two distinct 
things (which is made very clear by continuations).  I could take a 
snapshot of the stack, then later start it up again on a different 
process...suddenly, my ProcessEnvironment is gone...whereas, if that 
information is in the stack (where it belongs) you've got no problem.  
So, when doing certain things, you are forced to keep the stack and it's 
current ProcessEnvironmnet in sync.  It's important also to keep in mind 
what the role of Process is...it isn't actually responsibility for doing 
computations (that's the context stack), it's only job is to help with 
CPU scheduling.  With that view, it makes absolutely no sense to put 
state that is associated with computation there.

Besides, if you take this approach in Squeak, the debugger won't work at 
all with it (since the debugger uses a different process for debugging).

>VW's WebToolkit uses #doSomething:request:response and puts the session
>in the request. As I want to separate my 'application-level' sessions
>from these 'UI-level' sessions, I stash my own Session class instances
>in the WebToolkit Sessions, grab the one from the request session ASAP
>and stash it in the current process environment. Works like a charm, and
>I like it a lot (simple, and clear - dynamic bindings always have this
>'who knows what might be on the stack' trickiness with all shorts of
>potential shadowing problems, I thing adding a dict to Process is just
>as fine for most cases and certainly good enough for this case). 
>

And a ProcessEnvironment has this who knows what stack the process might 
be running trickiness.  Saying that dynamic bindings are tricky is like 
saying that exception handling is tricky (an exception handler is a 
dynamic binding after all)...they are tricky, until you understand them 
and know when it is appropriate to use them, and when it is not.  I'd 
recommend that you have another look at dynamic bindings.

>In fact, the only thing I do with VW's Session is really UI-level stuff
>(I store model bindings etcetera in there - that's all stuff where the
>request is necessary anyway to read form variables etcetera), all the
>interesting bits (current user, language settings, color scheme, who's
>website he's logged into, ...) are in my own Session class that's made
>available to the current process.
>
>Anyway, I'm pleading from ignorance here, as it has been a while since I
>looked at the Dynamic Bindings stuff, but I find the whole concept a bit
>icky so I'd vote for something simpler if possible..
>  
>

Well, I'd says that ProcessEnvironment (or my previous implementations 
of runtime environments) is much less simple than DynamicBindings.  If 
you're looking for similar behavior to ProcessEnvironment for storing a 
request, simply use:

Bindings clamp:
    [#CurrentHttpRequest binding: anHttpRequest
    #CurrentHttpRequest binding]

This will set and get the current http request for the duration that the 
block is executing, no matter what process happens to be executing it.  
Multiple processes running in the block will have their own binding for 
#CurrentHttpRequest.  You can store your session in the current 
HttpRequest if you like.

- Stephen