You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Ovidiu Predescu <ov...@apache.org> on 2002/12/03 08:17:23 UTC
Re: flowscript save-on-back
Hi Torsten,
[Cc-ed Daniel and cocoon-dev@apache.org 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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: flowscript save-on-back
Posted by Christopher Oliver <re...@verizon.net>.
Hi Daniel
Daniel Fagerstrom wrote:
>
> Interesting!! Could you tell a litle bit more about how this construct
> works? What corresponds to the try block in ordinary exception handling
There is no corresponding try block in this case. See section 2.2 in
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=102781075226697&w=2
>
>
> IMHO the above code is complicated to follow and requires good
> knowledge about how continuations work to be graspable. I prefer the
> construction Ovidius construction proposed as it abstracts away the
> use of continuations.
I agree, that you need to be aware of the existence of continuations.
> Futhermore, in general one need different code for collecting request
> parameters for different form pages.
You can provide different such catch blocks in each function that
collects request parameters.
>
> What about implementing Ovidius construction with the concepts you
> described? Maybe something like the following could work:
>
> // Similar to sendPage() in system.js
> function formSendPageAndWait(uri, bizData,
> collectRequestParametersFun, timeToLive)
> {
> catch (continue) {
> collectRequestParametersFun();
> }
> return sendPageAndWait(uri, bizData, collectRequestParametersFun,
> timeToLive);
> }
>
I think that would also work.
Regards,
Chris
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: flowscript save-on-back
Posted by Ovidiu Predescu <ov...@apache.org>.
On Thursday, Dec 5, 2002, at 03:21 US/Pacific, Daniel Fagerstrom wrote:
> Christopher Oliver wrote:
>
>> Ovidiu,
>>
>> I think the below would also work, without changing system.js or any
>> Java code by using Rhino with continuations extended JavaScript
>> syntax:
>>
>> [code snippet removed]
>
> Interesting!! Could you tell a litle bit more about how this construct
> works? What corresponds to the try block in ordinary exception > handling
You might also find interesting Christopher's documentation on the
continuations enabled Rhino:
ftp://ftp.primaryinterface.com/pub/rhino/README.TXT
>> [code snippet removed]
>
> IMHO the above code is complicated to follow and requires good
> knowledge about how continuations work to be graspable. I prefer the
> construction Ovidius construction proposed as it abstracts away the
> use of continuations. Futhermore, in general one need different code
> for collecting request parameters for different form pages.
>
> What about implementing Ovidius construction with the concepts you
> described? Maybe something like the following could work:
>
> // Similar to sendPage() in system.js
> function formSendPageAndWait(uri, bizData,
> collectRequestParametersFun, timeToLive)
> {
> catch (continue) {
> collectRequestParametersFun();
> }
> return sendPageAndWait(uri, bizData, collectRequestParametersFun,
> timeToLive);
> }
Yes, I think this could work fine. I'll give it a shot, once I have a
working Cocoon again.
--
Ovidiu Predescu <ov...@apache.org>
http://webweavertech.com/ovidiu/weblog/
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: flowscript save-on-back
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Christopher Oliver wrote:
> Ovidiu,
>
> I think the below would also work, without changing system.js or any
> Java code by using Rhino with continuations extended JavaScript syntax:
>
> catch (continue) {
> // The continuation I'm part of is about to be restored
> // code to handle that goes here.
> }
>
> catch (break) {
> // I'm about to be captured in a continuation
> // code to handle that goes here
> }
>
>
> Regards,
>
> Chris
Interesting!! Could you tell a litle bit more about how this construct
works? What corresponds to the try block in ordinary exception handling
> function multiPageForm()
> {
> var a, b, c;
>
> // Reset the local variables with form parameters from
> // the request if this call frame is part of a
> // continuation being restored.
> catch (continue)
> {
> a = cocoon.request.get("a");
> b = cocoon.request.get("b");
> c = cocoon.request.get("c");
> }
>
> sendPageAndWait("page1.html", {...});'
>
> // at this point 'a' contains the value of the request parameter
>
> ....
>
> sendPageAndWait("page2.html", {...});
>
> // at this point 'a' and 'b' contain the values of the request parameters
>
> ....
>
> sendPageAndWait("page3.html", {...});
>
> // at this point 'a'. 'b' and 'c' contain the values of the request
> parameters
>
> ....
> }
IMHO the above code is complicated to follow and requires good knowledge
about how continuations work to be graspable. I prefer the construction
Ovidius construction proposed as it abstracts away the use of
continuations. Futhermore, in general one need different code for
collecting request parameters for different form pages.
What about implementing Ovidius construction with the concepts you
described? Maybe something like the following could work:
// Similar to sendPage() in system.js
function formSendPageAndWait(uri, bizData, collectRequestParametersFun,
timeToLive)
{
catch (continue) {
collectRequestParametersFun();
}
return sendPageAndWait(uri, bizData, collectRequestParametersFun,
timeToLive);
}
Regards,
Daniel Fagerstrom
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: flowscript save-on-back
Posted by Ovidiu Predescu <ov...@apache.org>.
On Wednesday, Dec 4, 2002, at 22:50 US/Pacific, Christopher Oliver
wrote:
> Ovidiu,
>
> I think the below would also work, without changing system.js or any
> Java code by using Rhino with continuations extended JavaScript > syntax:
>
> catch (continue) {
> // The continuation I'm part of is about to be restored
> // code to handle that goes here.
> }
>
> catch (break) {
> // I'm about to be captured in a continuation
> // code to handle that goes here
> }
Very nice indeed, thanks for pointing it out! I completely forgot about
this feature. Very elegant solution!
Best regards,
Ovidiu
> function multiPageForm()
> {
> var a, b, c;
>
> // Reset the local variables with form parameters from
> // the request if this call frame is part of a
> // continuation being restored.
> catch (continue)
> {
> a = cocoon.request.get("a");
> b = cocoon.request.get("b");
> c = cocoon.request.get("c");
> }
>
> sendPageAndWait("page1.html", {...});'
>
> // at this point 'a' contains the value of the request parameter
>
> ....
>
> sendPageAndWait("page2.html", {...});
>
> // at this point 'a' and 'b' contain the values of the request
> parameters
>
> ....
>
> sendPageAndWait("page3.html", {...});
>
> // at this point 'a'. 'b' and 'c' contain the values of the request
> parameters
>
> ....
> }
>
>
>
> Ovidiu Predescu wrote:
>
>> Hi Torsten,
>>
>> [Cc-ed Daniel and cocoon-dev@apache.org 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: cocoon-dev-unsubscribe@xml.apache.org
>> For additional commands, email: cocoon-dev-help@xml.apache.org
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: flowscript save-on-back
Posted by Christopher Oliver <re...@verizon.net>.
Ovidiu,
I think the below would also work, without changing system.js or any
Java code by using Rhino with continuations extended JavaScript syntax:
catch (continue) {
// The continuation I'm part of is about to be restored
// code to handle that goes here.
}
catch (break) {
// I'm about to be captured in a continuation
// code to handle that goes here
}
Regards,
Chris
function multiPageForm()
{
var a, b, c;
// Reset the local variables with form parameters from
// the request if this call frame is part of a
// continuation being restored.
catch (continue)
{
a = cocoon.request.get("a");
b = cocoon.request.get("b");
c = cocoon.request.get("c");
}
sendPageAndWait("page1.html", {...});'
// at this point 'a' contains the value of the request parameter
....
sendPageAndWait("page2.html", {...});
// at this point 'a' and 'b' contain the values of the request parameters
....
sendPageAndWait("page3.html", {...});
// at this point 'a'. 'b' and 'c' contain the values of the request
parameters
....
}
Ovidiu Predescu wrote:
> Hi Torsten,
>
> [Cc-ed Daniel and cocoon-dev@apache.org 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: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org