Your solution looks quite concise.
If you use flowscript for all DB transaction, couldn't you have the
final page make the commit ?
Maybe you can invalidate the continuation created before, not sure how
to do that.
Hope this help.
-Baptiste
Tobia a écrit :
In my example I only had one form, so the client/server interaction was
like this sequence diagram (you will need a fixed font to see it):
Client Server (flowscript)
open the page w/ the form --GET--> function call
: \_ new Form()
: \_ showForm()
: \_ internal validation loop
display the form <······· \_ sendPageAndWait()
try and submit the form --POST-> \_ validation FAILS
redisplay the form <······· \_ sendPageAndWait()
try and submit the form (*) --POST-> \_ validation SUCCEEDS
: \_ DB operations
display the results <······· \_ final sendPage()
Read it like this:
1 ---> 2
3
5 <··· 4
The problem is, if the user doesn't get the final results page (for
whatever reason) she will hit refresh and the flowscript will resume
from (*), which is a Bad Thing.
With my addition, the last part of the sequence diagram looks like this:
try and submit the form --POST-> \_ validation SUCCEEDS
: \_ DB operations
: \_ redirectToGet()
: \_ createWebContinuation()
receive the redirect <······· \_ redirectTo()
follow the redirect (*) --GET--> \_ return
display the results <······· \_ final sendPage()
Any refresh will make the flowscript resume from (*), which is correct.
It seems to me that any non-trivial use of createWebContinuation() needs
a flag variable (var done in my example) and a subsequent test. Is that
correct? Am I missing something?
Tobia
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
