cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Oliver <res1c...@verizon.net>
Subject Re: flowscript save-on-back
Date Thu, 05 Dec 2002 06:50:38 GMT
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


Mime
View raw message