[Seaside] Question about #call:, continuations and responses

Julian Fitzell jfitzell at gmail.com
Thu Sep 18 17:00:54 UTC 2008


On Thu, Sep 18, 2008 at 6:35 PM, Karsten <karsten at heeg.de> wrote:
> Hi,
>
> When I do a #call:, a continuation is created and then the new component is
> added to the sender via decorations to render instead of the sender. During
> the #call: a render notification is raised and then the component is
> rendered on a stream and sent back to the browser in a response.

Sounds right.

> When I call #answer: later it will restore the continuation and the old
> stack is restored. When the component is rendered, does this render on the
> same stream that was used before?

No. A new process is forked in the session and the stack is thus only
restored back as far as that point. The response is always for the
current request.

> When I do a #call: in an Ajax callback, I also create a continuation, send a
> notification to stop the callback and then render something on the
> response-stream so that the new component is displayed. However, once the
> #answer: is sent and the continuation is continued i cannot write anything
> to the old stream as the old stream is no longer there. Same goes for the
> new stream,  that one was part of the old stack that called #answer:, which
> is discarded when the continuation restores.
>
> Is there a way to have a valid stream after the continuation is reset and be
> able to respond to the browser?

Well, you can't call #call: or #answer: in the rendering phase, and
you can't render in the action phase. If you're trying to #call: and
then render in the same method (after the #call: returns) something is
wrong.

I think the problem is that the AJAX callbacks don't do the normal
2-phase action/render sequence - you just receive a request and return
a response (it's more of an event-processing mechanism from the
server's point of view). I'm not sure that calling from an AJAX
callback makes sense.

Julian


More information about the seaside mailing list