On Tue, 9 Apr 2002 12:34:17 +0400 , Konstantin Piroumian <[EMAIL PROTECTED]> wrote:
> > In Schecoon you don't deal with continuations directly,
> > they're hidden under the cover. The only thing you see is a
> > sendPage() function, which sends the response page and
> > interrupts the processing, only to resume it later when the
> > following request comes along.
>
> What if you don't need to continue processing from an old position? Say, the
> user passed several steps in wizard and that resulted in some business
> calls. Returning back to one of the previous state would require a either an
> intelligent rollback of operations or an error message telling that the user
> cannot go back. With our XML flow approach each of this situations can be
> handled on developer's discretion.
You have fine control over the lifetime of created continuation. The
sendPage() function returns a continuation object, which can
manipulate directly if you want to.
Suppose the user has to complete a multipage form which is part of a
transaction. The script would look like this:
function transaction()
{
sendPage("start");
...
beginTransaction();
...
sendPage("page1");
...
sendPage("page2");
...
sendPage("page3");
...
commitTransaction();
...
sendPage("finish");
}
The user can go back and forth to modify values in the forms from
page1, page2 and page3. As soon as the user is presented with the
"finish" page, you want to disallow the ability to go back in the
browser history and modify the values in page1, 2 or 3.
The continuations are organized in a tree, with each node in the tree
being a continuation. If the user doesn't hit the "back" button in the
browser, and continues the computation with different values, the tree
of continuations degenerates to a list. E.g. in the above case, the
tree would look like:
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.
Now suppose the user reaches clicks the submit button on page3. When
this happens the "finish" page is generated, and the associated
continuation added in the tree:
start -> page1 -> page2 -> page3 -> finish
\
----> page2
This will commit the transaction started right after the "start"
page. Now suppose you want to disallow the user to hit the "back"
button and restart the computation, in _all_ the browser windows the
user started.
The only thing you need to do is invalidate the continuation
associated with the start page, which in turn will invalidate all the
continuations in its subtree. Invalidation means that you remove the
association between the continuation id present in all the user's
pages. You can associate those ids with a function that displays and
error page, telling the user he/she cannot go back after the
transaction has been completed. The modified script would look like
this:
function transaction()
{
var kstart = sendPage("start");
...
beginTransaction();
...
sendPage("page1");
...
sendPage("page2");
...
sendPage("page3");
...
commitTransaction();
// Invalidate all the continuations started from kstart, and
// associate their id with the "errorPage" function, which tells the
// user he/she cannot go back anymore.
kstart.invalidate(errorPage);
...
sendPage("finish");
}
function errorPage()
{
sendPage("errorPage");
}
You can also associate timeouts with the created continuations, so if
the user doesn't access the page in a while, they automatically
expire. I'm still working on this feature.
> > > Perhaps Ovidiu's proposed uses of continuations are elegant > >
> > > enough, or the current scripting/continuation-capture mechanism
> > > is > > efficient and minimal enough, to address both these
> > > concerns.
> >
> > The usage of the framework is fairly simple, and the notion of
> > continuation is not exposed explicitly when you're doing
> > programming as end user programmer.
>
> In some cases one would like to handle continuation explicitly. Is it
> possible now?
Yes, see the above example. I'm still working on finishing up some of
the features, but I hope you get an idea of how continuations are
manipulated.
> > I certainly hope Cocoon will change for the better in the very
> > near future.
>
> And we will do our best for that. One of the things that will make
> this happen is to develop more real world samples and
> applications. One of the reasons why Struts is more popular it's
> availabilty of good sample applications and best practices
> documents.
I know, that's why I was thinking to start working on the simple Web
site shopping application.
I hope this helps in understanding how continuations are used in
Schecoon. If not, please ask for more clarifications.
Best regards,
--
Ovidiu Predescu <[EMAIL PROTECTED]>
http://www.geocities.com/SiliconValley/Monitor/7464/ (GNU, Emacs, other stuff)
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
