cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bruyn Bill" <Bru...@mcao.maricopa.gov>
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 @ http://wiki.apache.org/cocoon/RhinoWithContinuations:
 
"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"
 
HTH,
 
Bill

________________________________

From: Craig Gulliver [mailto:cgulliver@alarmpoint.com]
Sent: Thu 3/16/2006 1:00 PM
To: users@cocoon.apache.org
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.

Thanks,

Craig

"Craig Gulliver" <cgulliver@alarmpoint.com> wrote in message
news:<6563DCB2E2AFBA4AACB3AC151A0B241D0985A5@mailserver.invoqsystems.com
>...
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" <salvetti.marc@gmail.com> wrote in message
news:<15786ae80603151939rcc8cbe5n@mail.gmail.com>...
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 <cgulliver@alarmpoint.com>:
>
>  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: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org




Mime
View raw message