cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bruyn Bill" <>
Subject RE: Back button issues with multipage forms
Date Thu, 16 Mar 2006 20:55:53 GMT
I'm not sure that I fully understand the problem at hand (sounds like a client-side problem
to me), but I think the answer to your question is no.  I was counting on being able to restore
the state of some variable at a particular continuation myself, but found the following buried
on the wiki @
"NOTE:  Captured continuation does not save the state of the variables, but rather pointers
to the variables.  Example: two continuations will share one instance of the local variable
declared in the function, if those two continuations were created during execution of the
same call of this function"


From: Craig Gulliver []
Sent: Thu 3/16/2006 1:00 PM
Subject: Re: Back button issues with multipage forms

It may be possible to provide this functionality using the
ProcessingPhaseListeners event handler.  The implementation of this
class would record the state of all form widgets on creation.  When
receiving an event that the LOAD_MODEL phase has ended, then the widget
state could be applied to form.  The question is, will continuations
restore the state of the ProcessingPhaseListener class so that the
proper states are applied to the form?

Does any of this sound reasonable to any one?  Maybe I should post my
questions to the developer forum.



"Craig Gulliver" <> wrote in message
Hi Marc,

Thanks for the reply.  We've considered this approach however it doesn't
work for our situation.  The problem is that the possible pages is
variable and dependent on data provided by the database.  For example, a
repeater widget that has multiple group widget containers per row, and
the user can swtich between each group widget effectively displaying a
different view of the data.

I'm considering another approach.

I've traced through the form processing code many times and have noticed
that the first task is to dispatch any queued events.  If I was able to
fit an event into that queue that set the state of the widgets, then I
could use continuations to store the widget state at each step and
provide that information in the event.  The result would be that widget
states would be correct, and the request processing would proceed at

I not certain that this is even possible.  I'm hoping that someone has
some experience around this area to lend some advice.

Thanks Again,


"Marc Salvetti" <> wrote in message
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
the same flowscript function.

You can also try to hack the pb with something like that :
    var submitWidget = widget.getForm().getSubmitWidget();
    while(submitWidget == null){
        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.



2006/3/15, Craig Gulliver <>:
>  I have several forms that use the multipage wizard.  The basic idea
> that the form has multiple group widget containers that can be hidden
> 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
> 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
> are not recorded at each continuation.  The result is that the form
> states do not revert.  In other words, the continuation does not have
> state when applied to the process.
> To illustrate:
> * Displaying form with group A and group B.  Group A is active, and
> B is invisible.
> * User submits the form using the flip button, the buttons event
> 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.
> form processing shows that the state is that in step 2 instead of step
> The state of these widget containers affect how the request is
> and explains the strange behaviour.
> Another item I came across was the use of page local.  The cocoon
> provides a function called createPageLocal.  The returned object is
used to
> store local page variables that can be restored when a page is
> (ie back button is used).  There is not much documentation surrounding
> feature.  I was not able to solve my problem using it.  Either I was
> it incorrectly, or it's the wrong solution.  Does anyone have any
> with this feature, and if so is there documentation for it.  Would it
> 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


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message