[Seaside-dev] hot to not use continuations

Julian Fitzell jfitzell at gmail.com
Thu Apr 9 10:34:58 UTC 2009


On Thu, Apr 2, 2009 at 11:31 PM, Sebastian Sastre <ssastre at seaswork.com>wrote:

> Folks, just for the record:
> I've found a cause of problems unless you're prepared:
>
> I was using a block with ifCurtailed: wrapping the process of action and
> rendering. By wrapping I mean someting about a filter depends on it.
>
> Incidentally, the ifCurtailed: was basically there to make a rollback
> and/or
> unlock any locked objects of a non flawless transaction.
> So, to prevent surprises, developers must expect WAResponseNotification at
> any
> time. This means that a non resumable notification will be triggered at any
> moment when the action/render block is evaluated.


Well, #handleFiltered: *may* return normally; WAResponseNotification is used
to indicate that a RequestHandler wants to *immediately* abort processing
and return a response. In practice though, when using RenderLoop, we pretty
much always signal a notification.


> As it's not resumable, the block will be evaluating the ifCurtailed even
> when
> all is perfectly fine.
>

The fact that the notification is non-resumeable is not really the issue.
The notification will always be caught by the ServerAdaptor and that will
cause the stack to be unwound, which causes your #ifCurtailed: to be called.
Your code *is* being abnormally terminated by a request to immediately
return a response.

Try executing this (which uses a resumeable notification) in a workspace,
for example:

[[nil notify: 1] ifCurtailed: [Transcript show: 'curtailed']]
    on: Notification do: []

Filters or request handlers can, of course, intercept the
WAResponseNotification and modify the Response as they see fit.

Julian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/seaside-dev/attachments/20090409/2ec8c963/attachment.htm


More information about the seaside-dev mailing list