Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 65177 invoked from network); 22 Oct 2003 17:43:41 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 22 Oct 2003 17:43:41 -0000 Received: (qmail 69480 invoked by uid 500); 22 Oct 2003 17:43:24 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 69444 invoked by uid 500); 22 Oct 2003 17:43:24 -0000 Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: dev@cocoon.apache.org Delivered-To: mailing list dev@cocoon.apache.org Received: (qmail 69383 invoked from network); 22 Oct 2003 17:43:24 -0000 Received: from unknown (HELO out012.verizon.net) (206.46.170.137) by daedalus.apache.org with SMTP; 22 Oct 2003 17:43:24 -0000 Received: from verizon.net ([4.40.114.87]) by out012.verizon.net (InterMail vM.5.01.05.33 201-253-122-126-133-20030313) with ESMTP id <20031022174327.WSUS20366.out012.verizon.net@verizon.net> for ; Wed, 22 Oct 2003 12:43:27 -0500 Message-ID: <3F96C1AF.5090303@verizon.net> Date: Wed, 22 Oct 2003 10:43:11 -0700 From: Christopher Oliver User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: dev@cocoon.apache.org Subject: Re: Thoughts on Woody ... References: <009001c39884$16dbe280$1e01a8c0@WRPO> <3F965A71.7070609@vafer.org> <3F967DD3.9070807@anyware-tech.com> <3F96999A.7000009@vafer.org> <3F96A4CE.4070103@anyware-tech.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH at out012.verizon.net from [4.40.114.87] at Wed, 22 Oct 2003 12:43:27 -0500 X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N 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"); wizard.show("first-page.html"); wizard.show("second-page.html"); wizard.show("third-page.html"); cocoon.sendPage("finished.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 >