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