[Seaside] Problem with continuations/flow.

[Tobias Pape]

Am 2011-05-24 um 12:02 schrieb Julian Fitzell:

> I'm pretty sure that code would have suffered from the same bugs, i.e.
> state would not be backtracked, so the user would be running in a
> session assuming it was in the condition of a particular request but
> actually in the state of whatever request happened to have been
> processed by that session most recently. However, the move to partial
> continuations means that it is now more overtly broken.
> 
> So... instead of using #inform: to tell the user an email has been
> sent to them, you could #call: a component. Inside that component's
> render method, you can use "url := html urlForAction [ self
> verifyAccount. self answer ]" to get a URL and then send the email.
> This isn't a *great* solution either, since we don't recommend
> performing actions (like sending an email) during the render phase,
> but currently you have no way of setting up callbacks in a task, so it
> may be the best you can easily do.
> 
> The other option is to create your own subclass of
> WASessionContinuation, which is a bit heavier-weight but probably a
> better idea. I'm actually in the middle of working on some code in
> Seaside that introduces a pluggable action continuation, which should
> make this kind of thing easier since you wouldn't have to create your
> own class. It should be possible to implement what you're trying to do
> in a task by wrapping the first class continuation in a CPS
> continuation, but I'll need to think a bit more about that - I'm
> meeting Nick to work on related stuff this afternoon anyway so I'll
> see what I can come up with.

Thanks Julian for the explanation.
Interestingly, it is working for the original 
SqueakSource. However I'm not reluctant to change the code.
I think, for SqueakSource, Dale has a working solution similar
to the one you stated with #urlForAction.

I'm interested in the outcome of your ‘journey’ into the 
Continuations :)

Best
	-Tobias