To throw in my two cents on the utility of continuations... :)
1) They are a compact way of representing complex, stateful control flow
(page-to-page) that otherwise would be represented in explicit state variables
and generalized functions, as Leslie observed.
2) I've come to the conclusion that they are nice theoretically, but that they
are overkill for most operations you tend to perform in web pages. In dialogs
and do-widget you are basically modeling a stack and when something goes wrong,
peering through the continuation structures to make sense of what is going on
is difficult. It took me awhile to get the knack of this. Now I pretty much
only use it for trivial cases like dialogs.
3) Apps with state are tough in general to make robust and user-friendly. I
tend to use a semi-stateless, REST style approach where my urls define a
general page context (like editor/document) but then use server side state via
AJAX/closures to represent what's going on within the editor for that document.
If you hit the back button, you go back to the prior document, if you go
forward again, you are returned to the same editor state so people quickly get
that back/forward navigates documents, and that local links/buttons manipulate
your view of that document.
For me the biggest asset of weblocks has been the excellent infrastructure for
supporting AJAX via server side modification of client widget, the widget
architecture (now that the navigation has been cleaned up). Except for
prototyping or rare cases where it worked out, I don't use the generic widgets
and views but should probably revisit that now that the team has spent the
better part of the last year improving them!
Best,
Ian
On Dec 14, 2009, at 2:36 PM, Leslie P. Polzer wrote:
>
> 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.
>
>
--
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.
