[Cc-ed Daniel and [EMAIL PROTECTED] as it might be an interesting topic as well]
Sorry it took so long for me to find some more time to think about this problem.
I believe the use case you mentioned is certainly a valid one, and a very important one. One way to solve this problem is to come up with other abstractions built on top of what is already there.
One idea that comes to mind is to invent a wrapper function for the sendPage*() function, which takes as an additional argument a function. This function is called right after the continuation has been restored, e.g. when the processing resumes, to setup values of local variables depending on the request parameters. In practice this function could be used to collect all the request parameters for the multi-page form. This approach takes advantage of the nested functions concept available in JavaScript.
Here is a simple example. Suppose we have a multi-page form which collects "a" in the first page, "b" in the second one, "c" in the third one etc. What we want is to have a, b, c local variables in a function. These local variables would be set from the request parameters. The sample would look like this:
// -------- new functions in system.js
// Similar to sendPage() in system.js
function formSendPage(uri, bizData, collectRequestParametersFun, timeToLive)
{
var kont = _sendPage(uri, bizData, collectRequestParametersFun, timeToLive);
lastContinuation = kont;
return kont;
}
// Similar to _sendPage() in system.js
function _sendPage(uri, bizData, collectRequestParametersFun, timeToLive)
{
var k = new Continuation();
var kont = new WebContinuation(cocoon, k, lastContinuation, timeToLive);
cocoon.forwardTo("cocoon://" + cocoon.environment.getURIPrefix() + uri,
bizData, kont);
kont.setCollectParamsFunction(collectRequestParametersFun);
suicide();
}
// overrides handleContinuation() from system.js
function handleContinuation(kont)
{
var collectRequestParametersFun = kont.getCollectParamsFunction();
// Call the function to obtain the request parameters
collectRequestParametersFun();
kont.continuation(kont);
}
// ------------ end of functions in system.js
// ------------ application code
function multiPageForm()
{
var a, b, c;
// This nested function sets the value of the local variables define outside it
// in the enclosing function
function collectParameters()
{
a = cocoon.request.get("a");
b = cocoon.request.get("b");
c = cocoon.request.get("c");
}
formSendPage("page1.html", {...}, collectParameters);
// at this point 'a' contains the value of the request parameter
....
formSendPage("page2.html", {...}, collectParameters);
// at this point 'a' and 'b' contain the values of the request parameters
....
formSendPage("page3.html", {...}, collectParameters);
// at this point 'a'. 'b' and 'c' contain the values of the request parameters
....
}
Going back in the history by jumping to the appropriate continuation will automatically save the value of the JavaScript variables based on the request parameters.
The above scenario requires only minor changes to JSWebContinuation to add the setCollectParamsFunction() and getCollectParamsFunction() methods.
I think this solves the problem you outlined in your email. Am I missing something here?
Ovidiu
On Thursday, Nov 21, 2002, at 17:37 US/Pacific, Torsten Curdt wrote:
Hi, Ovidiu! I hope you had a good trip back home. On my way back from Belgium I was trying to sort all those ideas and talks we had about the flowscript. The last night after you guys headed off I had a conversation with Daniel Fogerstrom about the flowscript that worried me a little... He pointed me on something that I/we have overlooked somehow. Let me call it the save-on-back problem;)Let think about the XMLForm wizard example. This should be very easy with flowscript. Basically we would have some sendPages plus population and validation. Going back could be done by going back to the parent continuation object. Sounds good - on the first glance. But let's assume the following view already transformed into HTML: <form action="cont/123456"> <input type="textbox" name="name"> <input type="textbox" name="email"> <input type="submit" name="cocoon-button-next" value="next"> </form> Now lets add the back button... a link or form pointing to the parent continuation object: <form action="cont/123456"> <input type="textbox" name="name"> <input type="textbox" name="email"> <input type="submit" name="cocoon-button-next" value="next"> </form> <a href="cont/45676">Go Back</a> <form action="cont/45676"> <input type="submit" value="Go Back"> </form> A common customer requirement is to save the values of the current view into the model before going back. This is not possible when using a link since the form fields are missing in the request (besides they would need to be saved in the other/current continuation anyway) Same problem applies when using a different form. Only thing that I could think of is for such (common) use cases to go back through the flowscript/controller. <form action="cont/123456"> <input type="textbox" name="name"> <input type="textbox" name="email"> <input type="submit" name="cocoon-button-back" value="Go back"> <input type="submit" name="cocoon-button-next" value="next"> </form> ..and catch the back button in the controller just like any other button. ...sendPage(...) button = request[... starting with "cocoon-button-" ]; if (button == "back") ... if (button == "next") ... But then we would need to have a way to go back to the parent continuation inside the flowscript itself... :-/ Besides that I came across the idea specifying the continuation not in the URI but in the request parameter like this: <input type="submit" name="cocoon-cont-12341" value="Go back"> What do you think about all this? Anyway it would be great if you could try to implement the XMLForm wizard example how you think it "should" be done with flowscript. All the best -- Torsten
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
