cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ovidiu Predescu <ovi...@apache.org>
Subject Re: flowscript save-on-back
Date Thu, 05 Dec 2002 07:34:48 GMT

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


Mime
View raw message