Chris Double has yet more info on his fledgling continuation-based framework. It's great to have someone else discussing this stuff, because it motivates me to talk about some parts of Seaside I might not have otherwise. Although I've already heard a couple of times that we should "start a mailing list or something" because it would make the discussion easier to follow...
Anyway, the latest post from Chris is on expiring continuations transactionally. This is crucial: a big part of seamlessly supporting the back button is restricting its usage when it's not appropiate. For example, say you're writing a shopping cart application. Once the user has entered their credit card info and the order has been marked as paid, you don't want them to be able to back up and start adding more items to the order. At that point, you need to expire any continuation that was captured since that order was begun - that is, you need to make any link or button on any page that was presented while building the order, become inoperative.
Seaside does this with an #isolate: method. You can wrap a block of code in an #isolate: call, like so:
As soon as the flow hits showOrderConfirmationPage, any links in the shopping pages will become immediately invalid. Until that point, however, the user is free to use the back button all they want.
This is implemented as part of a generic filter facility. At any point, there is a stack of active filter objects; methods like #isolate: push a new filter on, evaluate the block, and then pop it off again. When a continuation is resumed, the incoming request has to go through all of the filters that were active when that continuation was captured before it actually gets processed by the application code. The Transaction filter lets all requests through until its "completed" flag is set (which happens at the same time as it is popped off the stack), after which point it won't let any through at all. Another filter is the Once filter, which lets each page get exactly one request from the user - any further requests to the identical continuation will be disallowed. The other one in common use in Seaside performs HTTP basic authentication. This means that you can easily authenticate for only certain actions - if some piece of code needs authentication, you wrap it in a block something like this:
self session
authenticateWith: [:user :password | ... return true or false ...]
during: [... do something privileged ... ]
As a side note, it seems like these postings have become more technical and probably harder for the casual reader (ie, someone not implemeting a similar framework) to follow... if that's true, then please, leave nasty comments telling me so.
Previous Topic
