[Seaside] Seaside and Dynamic variables

David Shaffer cdshaffer at acm.org
Wed Nov 16 18:14:28 CET 2005

I've seen the common pattern:

SomeSession>>withEscapeContinuation: aBlock
    ^SomeDynamicVariable use: someValue duing: [super
withEscapeContinuation: aBlock]

or similar using the DynamicVariables package:

SomeSession>>withEscapeContinuation: aBlock
    ^Bindings clamp: [someSymbol binding: someValue.
          super withEscapeContinuation: aBlock]

and both of these work in the simple case where the binding's value (ie
"someValue") is currect the _first_ time withEscapeContinuation: is
invoked.  Subsequent requests' invocations of withEscapeContinuation:
are not on the stack during the actual callback handling, rendering
etc....only the first one...or at least that's what makes sense to me. 
But I think that the code (above) is misleading...it certainly gave *me*
the impression that each request would have its own binding context.  I
had a case last night where I needed a dynamic variable but didn't know
its value on the first invocation...so, I used this pattern:

SomeSession>>start: aRequest
    ^Bindings clamp: [^super start: aRequest]     "this gets me one
dynamic binding context use for all future requests to this session"

and either:

SomeSession>>someVariable: aValue
    ^#someVariable binding: aValue


SomeSession>>withEscapeContinuation: aBlock
    #someVariable binding: someValue.
    ^super withEscapeContinuation: aBlock

This seems to work very well and prompts me to wonder if we should avoid
the first version of the pattern.   Am I nuts?  The "once in and out"
per request of withEscapeContinuation: makes it useful for database
session creation etc but not so useful for dynamic variable binding. 
I'd like to add this to the FAQ if I'm not right...just want some
independent confirmation that this is a reasonable pattern.


More information about the Seaside mailing list