cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Oliver <>
Subject Re: Thoughts on Woody ...
Date Wed, 22 Oct 2003 17:43:11 GMT
I think you're making this much more complicated than it needs to be. 
Please look at how JXForms does this. First it creates a continuation 
immediately before and immediately after a page is sent to the browser. 
The latter continuation behaves exactly like sendPageAndWait(). However, 
by invoking the former you cause the page to be resent (and processing 
to restart when that page is resubmitted). So:

1) If you invoke the current continuation processing continues after the 
current page is submitted.
2) If you invoke its parent continuation the current page is resent to 
the browser.
3) If you invoke the grandparent continuation the actions following 
submission of the previous page are replayed.
4) If you invoke the great-grandparent continuation the previous page is 
resent to the browser.

So to implement the "back" button, you invoke (4).

The idea is that instead of only encoding the continuation id in the 
form or request url, you also associate a "forward" or "back" action 
with the submit button. The form submits are _always_ submitted to the 
same location, where some Java or JavaScript code looks at the 
continuation id together with "forward" or "back" indication of the 
submit button. If the indication is "forward" then you simply look up 
the continuation associated with the continuation id and invoke it. But 
if the indication is "back" then you invoke the great-grandparent of the 
continuation. With this approach your example reduces to this (and most 
importantly you don't have to explicitly code back/forward navigation in 
your flow script):

function myWizard() {
    var wizard = new Wizard("wizard-spec.xml");"first-page.html");"second-page.html");"third-page.html");

Sylvain Wallez wrote:

> Torsten Curdt wrote:
>>> No problem with the wizard approach I suggested: the form contains a 
>>> link only to *one* continuation (the one that displayed the current 
>>> page), and upon post, the wizard ressurects the previous continuation.
>>> This means that the current form can be populated and then the 
>>> previous one displayed.
>> ok, so let's the say the back button is linked (via POST) to the
>> exact same continuation that got us to that particular view - how
>> should we actually control to go back to the previous one? we are
>> asking for the same one!
>> sorry, don't get that...
> Let's look again at the (still hypothetical) wizard library:
> function myWizard() {
> var wizard = new Wizard();
> // register the current execution location as a backtrack point
> wizard.markStep();
> cocoon.sendPageAndWait("first-page.html");
> var value = cocoon.request.getParameter("value");
> wizard.markStep();
> if (value == "foo") {
>   cocoon.sendPageAndWait("foo-page.html");
>   wizard.handleBack();
> } else {
>   cocoon.sendPageAndWait("bar-page.html");
>   wizard.handleBack();
> }
> wizard.markStep();
> cocoon.sendPageAndWait("third-page.html");
> wizard.handleBack();
> cocoon.sendPage("finished.html");
> }
> The wizard object contains a stack of continuations. When 
> wizard.markStep() is called, a continuation corresponding to the 
> current location is added on the top of the stack. Notice how 
> wizard.markStep() is called before every page is displayed: this will 
> allow us to go back just before that display.
> In wizard.handleBack(), we examine the request for a particular 
> request parameter that indicates that the "previous" button was 
> clicked. If we find this, we pop _two_ continuations from the stack 
> (the first one would just redisplay the same page) and restore that 
> continuation.
> When that popped continuation is restored, flowscript execution goes 
> back to the wizard.markStep() statement where this continuation was 
> pushed on the stack. We then redisplay the previous page.
> Is it clearer?
> Note: (argh, I will obscure things again) implementation-wise, we 
> can't just have a stack in the wizard object, as it would have the 
> same value for all continuations (remember, once an object is 
> declared, its is shared by all descendant continuations). We need a 
> "ContinuationLocal" variable, analogous to "InheritableThreadLocal" 
> but for continuations, i.e. the value will be different for every 
> continuation. This is not available today, even if I have some ideas 
> on how to do it.
> Sylvain

View raw message