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
expected.
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,
Craig
"Marc Salvetti" <[EMAIL PROTECTED]> wrote in message
news:<[EMAIL PROTECTED]>...
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
>
>
>
>
>
----------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
