Hi Craig,

i did run into the problem, and i didn't find other satisfiying solution than to cut down my multipage form to several forms called successively from the same flowscript function.

You can also try to hack the pb with something like that :
    var submitWidget = widget.getForm().getSubmitWidget();
    while(submitWidget == null){
        form.showForm(displayPipeline);
        submitWidget = widget.getForm().getSubmitWidget();
        //Protect from the bug when user press the back button
        if(submitWidget == null){           
            cocoon.log.debug("back button pressed");

But i find it more difficult and less elegant than successive forms.

hth,

Marc

2006/3/15, Craig Gulliver <[EMAIL PROTECTED]>:

I have several forms that use the multipage wizard.  The basic idea is that the form has multiple group widget containers that can be hidden or displayed based on user actions(ie button clicks really).  And are controlled using button event handers (on-action events) in the form definition.

 

My problem is stemming from the use of the back button with these types of pages.

 

The first thing I investigated was how continuations would solve my problem.  It seemed like the right candidate to provide a solution.  I turns out that even with continuations these forms still do not behave as I expect.  I tracked the issue down to the fact that the form and it's state are not recorded at each continuation.  The result is that the form widget states do not revert.  In other words, the continuation does not have this state when applied to the process.

 

To illustrate:

 

* Displaying form with group A and group B.  Group A is active, and Group B is invisible.

 

* User submits the form using the flip button, the buttons event handler flips the state of each Group so that A is invisible and B is active.

 

* User hits the browser back button, then hits the flip button again.  The form processing shows that the state is that in step 2 instead of step 1.  The state of these widget containers affect how the request is processed, and explains the strange behaviour.

 

Another item I came across was the use of page local.  The cocoon object provides a function called createPageLocal.  The returned object is used to store local page variables that can be restored when a page is resubmitted (ie back button is used).  There is not much documentation surrounding this feature.  I was not able to solve my problem using it.  Either I was using it incorrectly, or it's the wrong solution.  Does anyone have any experience with this feature, and if so is there documentation for it.  Would it solve my problem, or am I running down a rabbit hole?

 

I would think that we are not the first to run into this problem.  However, I have not found any mention of it on the forums, wiki, or supporting cocoon sites.

 

Does anyone have an answer to this problem?

 

Thanks in advance,

 

 

Craig W Gulliver 

 

 


Reply via email to