Rayservers wrote:
> A continuation system is, at the bottom of it, a way of persisting and
> maintaining state in an inherently stateless protocol. The continuation
> parameter serves as that. I've put my understanding down in my own words here.
Yes. That's a quite abstract definition but I can't find anything wrong
with it.
> How would you distinguish this from maintaining state in the widget (what I
> did)
> or a database?
Continuations maintain the state of the code execution flow. They come
in handy when your state is best modelled by a continuation function
("what code will I execute next").
Often an alternative is easier to comprehend and use. Let's take a "Wizard"
page flow as example. If there's a linear relationship between pages then
we can just model them with a list of widgets and a pointer to the current.
However if we have a tree relationship where a page can be reached by
multiple predecessor it's way easier to just call the continuation from the
"Back" link that restores the previous widget.
Of course you could also directly store the widget here, but keep in mind that
this is a simplified case; you might want to do other things programmatically
besides restoring the previous widget, and we all know that functions do that
best. Without continuations you could only store the old data and let a
generalized function interpret that while with continuations you just keep
old of the rest of the computation.
Leslie
--
You received this message because you are subscribed to the Google Groups
"weblocks" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/weblocks?hl=en.
