Ovidiu,
I have followed your work on Schecoon with great interest. I share the view
that structured program constructs: sequence, choice and repeat are a much
better and natural way to describe control flow in webapps, compared to
finite state machines. That said, I'm not totally enthusiastic about the
introduction of yet another program language in my webapps. But before
seeing some more realistic examples I've no strong opinions.
Concerning the continuation part: IMO the idea of letting the flow control
mechanism sending the continuation (post) address to the form pages is very
elegant, however, I'm starting to get somewhat worried about the memory
(session state) model, but hopefully I've just got it wrong.
To the point:
We all know that continuations handle the back button like magic, but what
about the forward button?
Ovidiu Predescu wrote:
> start -> page1 -> page2 -> page3
>
> If the user goes back to page1 for example, or creates a new browser
> window which displays page1, then changes some values in this page and
> hits the submit button, the tree would look like this:
>
> start -> page1 -> page2 -> page3
> \
> ----> page2
>
> This is a great way for the user to experiment with "what if"
> scenarios. How many times you went to Amazon and played with the
> shopping cart to see which items you can buy? This is a very good
> example of such a scenario.
Lets instantiate your example:
Buying a book (#1) -> buying another book (#2) -> buying still another book
(#3) -> ... (yes I like buying books :) ) ... -> giving my credit card
number (#10) -> filling in all the address info (#11) -> the commit page
(#12)
IIUC, the continuation hash code #1 point to the state (stack) of the
program as it were when I put the first book in the shopping car, code #2 to
the program state as it were when I took the second book and so on.
Back to the example: seeing the total price on the commit page, I suddenly
realize that I don't really need the second book. So I go back to the second
page, perform the necessary changes and hit the submit button. Now the
server start to work from the state indexed by code #2 and starts to put the
new submit info in the appropriate Schecoon variables, this is done in a new
and fresh part of the program state tree.
book (#1) -> book (#2) -> book (#3)... -> address (#11) -> the commit page
(#12)
\
-> book (#3a) -> ???
At this moment, I start to wonder how to get back to all the information I
had submitted to continuation #11, so that I can commit that info, but
without buying the second book.
So, are "what if" scenarios really the best way to do web shopping? Or did I
completely miss the point? Or is there a better way to describe the web
shopping scenario, where the above indicated problems doesn't appear?
/Daniel Fagerstrom
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
