One additional piece of “workflow management”. It can be a bit controversial because it changes the state of the back button to something the user is not expecting. However, when there are situations where you are half way through a transaction, of which hitting the back button would have negative impact, sometimes there’s just no other way.

What I’m refering to is document.replace, which will replace not only the current document, but will replace the history stack with the same URI, so hitting the back button, in essence, takes you to the same place you are already at, and hitting it twice takes you to the beginning of the transaction (if used correctly.)

There are four possibilities:

1) Store the continuation in the URL. This is perfect if you can make it small enough to fit within the constraints of usable URLs.

2) Store the continuation on the server and use the URL as a key to find it. The difficulty here is that you have to throw these away eventually or the server runs out of space. When is it safe to discard the continuation? You have to guess. (Naturally, you mustn’t ever reuse such a key, but that’s fairly easy to arrange.)

3) Store the continuation on the client in a cookie. Same issue as #1, but less limited.

4) Store the continuation in hidden fields. The trouble with this is that in order to save, the user has to save the whole page, not just the URL. Most users aren’t used to that idea.

My best idea so far is a combination of #2 and #4. Store the whole page, complete with hidden fields, on the server and return an URL to it. People who bookmark the page will fetch it from the server and can carry on from there. Eventually the server will have to discard the page, after which bookmarking won’t work, but those who have been forethoughtful enough to save the page locally will still be able to carry on safely. Do your best to warn people of the necessity of
saving if they are going to leave the page for, say, a day (or whatever the server’s garbage-collection threshold is).

http://community.schemewiki.org/?composable-continuations-tutorial

And there’s no rule that says you can’t serialize continuations and put them in a hidden field on a client instead of on the server.

Personally, I prefer to use the URL over hidden fields when it makes sense. You can even post to a URL that has get parameters in a query string, but that’s probably getting too strange.

I do see what you’re getting at, though; make the webapp pages be entirely atomic, to prevent problems with needing to maintain state in the back end.