Aack!

[Mark Lundquist <ml...@comcast.net>]

OK Cocooners, here is the deal.

I'm porting a woo... er, CForms form from 2.1.3 to 2.1.4.  Before, 
without <wd:action> I had to emulate that myself.  I hacked my own 
showForm() that checked the request to figure out which button was 
pressed, and it only invoked validation if a particular one of the form 
buttons was pressed (the "Update" button, which conceptually is the 
real "submit" control, i.e. whose intent is to finalize the form 
processing).

So I thought I'd switch to using action and submit widgets in 2.1.4.  
But there's a problem.

In my hacked-over showForm(), if the form was submitted by something 
other than the "Update" button, I not only bypassed validation, but I 
exited showForm()'s loop and returned.  That took me back to the "outer 
loop" in my flow that checked the request to find out which button was 
pressed.  This was essential, because some of the other buttons do 
things that affect the display of the page.  So redisplaying the form 
entailed a new invocation of sendPageAndWait() in the next iteration of 
the loop, with potentially different bizdata.

When I switched to <wd:action>, this broke... my event handlers fired, 
so the model has changed, but I'm stuck in showForm()'s loop with stale 
bizdata until showForm() decides that form processing is finished 
(i.e., validation succeeded).

Can someone tell me how do I fix this?

Thanks,
Mark


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org

Re: Bookmark continuations (was Re: Aack!)

[Christopher Oliver <re...@verizon.net>]

Sorry, I think this is post 2.1.4. You'll need to get the CVS version. 
The example flowscript shows how to use it.

Chris

Mark Lundquist wrote:

> (I changed the subject line now that I have a clue what this is 
> about... "Aack!" is not very helpful to the community, me thinks :-)
>
> On Mar 10, 2004, at 7:25 AM, Christopher Oliver wrote:
>
>     See the use of form.setBookmark() in the v2 API. It allows you to
>     reacquire your bizData each time the form is redisplayed.
>
>     Chris
>
>
> Thanks Chris... sounds like this will help.
>
> I checked the samples... the only example of bookmarking continuations 
> is the "back" button in a multipage ('wizard') form sequence. No 
> example of setBookmark(). I tried searching the v2 API itself, the FOM 
> source code, and finally Google, and came up bone-dry.
>
> Then I ran across this, right there in the "Advanced Flow Control" 
> page of the Cocoon docs:
>
> *createWebContinuation
>
> */Function/ [WebContinuation] createWebContinuation()
>
> Creates a new "bookmark" WebContinuation object. When invoked it will 
> cause the script to resume right after the call. By calling this 
> function prior to sendPageAndWait() you can be create a "bookmark" 
> which will cause the page to be redisplayed in the browser. Note: the 
> WebContinuation associated with sendPageAndWait() doesn't do this. 
> Rather it resumes execution after the the page is submitted.
>
> For example:
>
> function processPage() {
>
> var bkm = cocoon.createWebContinuation();
> var biz = getBizData();
> cocoon.sendPageAndWait("uri",
> {bookmark: bkm, biz: biz},
> function() { releaseData(biz); });
> }
>
>
> This looks like it might be on the right track... is it? If so, I have 
> some more questions... I don't understand at all what is going on in 
> the call to sendPageAndWait in this example. So there's this 
> javascript object literal:
>
> {bookmark: bkm, biz: biz}
>
> and it would seem that this object /is/ the bizdata as far as 
> sendPageAndWait is concerned...? So I'm confused about where/how the 
> 'bookmark' property of that object achieves it effect. The doc says 
> what the bookmark will do "when invoked"... but how/where is it 
> invoked? Looking at the implementation of sendPageAndWait, it always 
> creates a new WebContinuation to pass to sendPage... Do I still 
> specify the <form action="..."> in the same way, or am I supposed to 
> reference previousContinuation or something, or what?
>
> And all this begs the question of how to use this bookmark approach 
> with the Woody/Flow integration, where you want to be calling 
> showForm() instead of sendPageAndWait() directly... and in particular, 
> with the v2 API, where apparently the widget tree is the (implicit) 
> bizdata (?)
>
> So many questions... so little time to get all this working... :-/
>
> Thanks a /lot/ for all the help so far!
> Mark
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org

Bookmark continuations (was Re: Aack!)

[Mark Lundquist <ml...@wrinkledog.com>]

(I changed the subject line now that I have a clue what this is 
about... "Aack!" is not very helpful to the community, me thinks :-)

On Mar 10, 2004, at 7:25 AM, Christopher Oliver wrote:

> See the use of form.setBookmark() in the v2 API. It allows you to 
> reacquire your bizData each time the form is redisplayed.
>
> Chris

Thanks Chris... sounds like this will help.

I checked the samples... the only example of bookmarking continuations 
is the "back" button in a multipage ('wizard') form sequence.  No 
example of setBookmark().  I tried searching the v2 API itself, the FOM 
source code, and finally Google, and came up bone-dry.

Then I ran across this, right there in the "Advanced Flow Control" page 
of the Cocoon docs:

createWebContinuation

Function [WebContinuation] createWebContinuation()

Creates a new "bookmark" WebContinuation object. When invoked it will 
cause the script to resume right after the call. By calling this 
function prior to sendPageAndWait() you can be create a "bookmark" 
which will cause the page to be redisplayed in the browser. Note: the 
WebContinuation associated with sendPageAndWait() doesn't do this. 
Rather it resumes execution after the the page is submitted.

  For example:

function processPage() {

   var bkm = cocoon.createWebContinuation();
   var biz = getBizData();
   cocoon.sendPageAndWait("uri",
                          {bookmark: bkm, biz: biz},
                          function() { releaseData(biz); });
}


This looks like it might be on the right track... is it?  If so, I have 
some more questions...  I don't understand at all what is going on in 
the call to sendPageAndWait in this example.  So there's this 
javascript object literal:

	{bookmark: bkm, biz: biz}

and it would seem that this object is the bizdata as far as 
sendPageAndWait is concerned...?  So I'm confused about where/how the 
'bookmark' property of that object achieves it effect. The doc says 
what the bookmark will do "when invoked"... but how/where is it 
invoked?  Looking at the implementation of sendPageAndWait, it always 
creates a new WebContinuation to pass to sendPage... Do I still specify 
the <form action="..."> in the same way, or am I supposed to reference 
previousContinuation or something, or what?

And all this begs the question of how to use this bookmark approach 
with the Woody/Flow integration, where you want to be calling 
showForm() instead of sendPageAndWait() directly... and in particular, 
with the v2 API, where apparently the widget tree is the (implicit) 
bizdata (?)

So many questions... so little time to get all this working... :-/

Thanks a lot for all the help so far!
Mark

Re: Aack!

[Christopher Oliver <re...@verizon.net>]

See the use of form.setBookmark() in the v2 API. It allows you to 
reacquire your bizData each time the form is redisplayed.

Chris

Mark Lundquist wrote:

> OK Cocooners, here is the deal.
>
> I'm porting a woo... er, CForms form from 2.1.3 to 2.1.4.  Before, 
> without <wd:action> I had to emulate that myself.  I hacked my own 
> showForm() that checked the request to figure out which button was 
> pressed, and it only invoked validation if a particular one of the 
> form buttons was pressed (the "Update" button, which conceptually is 
> the real "submit" control, i.e. whose intent is to finalize the form 
> processing).
>
> So I thought I'd switch to using action and submit widgets in 2.1.4.  
> But there's a problem.
>
> In my hacked-over showForm(), if the form was submitted by something 
> other than the "Update" button, I not only bypassed validation, but I 
> exited showForm()'s loop and returned.  That took me back to the 
> "outer loop" in my flow that checked the request to find out which 
> button was pressed.  This was essential, because some of the other 
> buttons do things that affect the display of the page.  So 
> redisplaying the form entailed a new invocation of sendPageAndWait() 
> in the next iteration of the loop, with potentially different bizdata.
>
> When I switched to <wd:action>, this broke... my event handlers fired, 
> so the model has changed, but I'm stuck in showForm()'s loop with 
> stale bizdata until showForm() decides that form processing is 
> finished (i.e., validation succeeded).
>
> Can someone tell me how do I fix this?
>
> Thanks,
> Mark
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org