How would this be fixed with client-side state saving? Here is what occurs in the JSF lifecycle. Correct me if I'm wrong:
User submits a form: -JSF attempts to restore the state of the view (the view could be stored on the server in a session of on the client). -If the view is the same as the one the user submitted the form to, continue processing [ at this point, we're fine ]. - else load the view (from the session or client), and call renderResponse(); [this is what causes us to need two form submits ]. I think this behavior is mandated by the JSF spec, but I could be wrong about that too. On Mon, 15 Nov 2004 16:33:00 +0100, Manfred Geiler <[EMAIL PROTECTED]> wrote: > Hi all, > Seems that some issues are getting mixed up here. > The Sun problem and fix that you mention is the "Use of Browser's > back-button causes multiple ActionEvents to pile up" problem. This > problem is resolved in MyFaces and it was resolved long before Sun RI. > What was the initial post for this thread was: > "When I navigate back to a form that has previously been submitted, > using the browser back button, I need to click the submit button twice > in order for the form to actually resubmit" > Well, I'm sure this problem does not exist for client-side state saving. > (There is another issue the "Serializable" thing, which is also fixed > now - use latest CVS please) > Regarding server-side state saving: Please give us an exact testcase > that can be used to reproduce this problem. > > Thanks, > Manfred > > > > > Dave Sag wrote: > > that's right. the change is in sun's reference implementation. the fix > > is in their CVS server now. i am very impressed with the way they > > handled the issue. i reported it as a bug in their issue tracker and > > within days several fixes were made. these were then discussed and > > thrashed around and within a week or so the changes were QA'd and code > > reviewed. very very professional. > > > > still, as i have said before - use what works - it only takes 2 seconds > > to swap JSF-RI and MyFaces in and out. > > > > cheers > > > > dave > > > > > > > > On 15/11/2004, at 3:59 PM, Matthias Wessendorf wrote: > > > >> spec from JSF 1.2 is not final now. > >> it will be included in J2EE 5 (aka 1.5) > >> > >> the fix is a fix for RI from SUN. > >> > >> as far as I can see... > >> > >> HTH, > >> Matthias > >> > >>> -----Original Message----- > >>> From: Heath Borders-Wing [mailto:[EMAIL PROTECTED] > >>> Sent: Monday, November 15, 2004 3:58 PM > >>> To: MyFaces Discussion > >>> Subject: Re: Back Button problems > >>> > >>> > >>> So, has JSF 1.2 been finalized now? Or is this just a beta version? > >>> > >>> > >>> On Mon, 15 Nov 2004 15:45:45 +0100, Dave Sag > >>> <[EMAIL PROTECTED]> wrote: > >>> > >>>> we tried that, and even tried setting the expires and > >>> > >>> pragma=no-cache > >>> > >>>> using a filter but it had no effect. the back button always just > >>>> grabs the last page from cache and does not even re-execute > >>> > >>> any onload > >>> > >>>> javascript in the page. > >>>> > >>>> the problems has however been resolved in JSF1.2 (see > >>> > >>> Issue: jsf-ri 63 > >>> > >>>> > >>> https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=63) so we > >>> > >>>> have switched back to sun's JSF for now. isn't choice a wonderful > >>>> thing. > >>>> > >>>> cheers > >>>> > >>>> dave > >>>> > >>>> > >>>> > >>>> On 15/11/2004, at 3:19 PM, Thomas Wolf wrote: > >>>> > >>>>> I'm a little rusty on my HTTP, but I don't think that hitting the > >>>>> "back" button always gets things from the browser's cache - > >>>>> specifically, I'm thinking about the "Expires" and the > >>>>> "Cache-Control" HTTP response headers that can be sent along with > >>>>> the original page: e.g. if the server sets the "no-cache" > >>> > >>> option on > >>> > >>>>> Cache-Control or sets an Expires date that's in the past, > >>> > >>> then the > >>> > >>>>> browser shouldn't use a cached page. > >>>>> > >>>>> I'm a newsbie when it comes to JSF, but does JSF not set these > >>>>> headers? In theory, this would solve the synchronization > >>> > >>> issue that > >>> > >>>>> is being mentioned: when the <back> button is hit, the browser > >>>>> should go to the server to re-fetch the page; JSF should > >>> > >>> be able to > >>> > >>>>> synchronize off that request, no? > >>>>> > >>>>> But maybe my memory on the caching stuff is a bit stale...can't > >>>>> remember if all browsers implemented it to spec. > >>>>> > >>>>> Hope this helps, > >>>>> tom > >>>>> > >>>>> > >>>>> -----Original Message----- > >>>>> From: Heath Borders-Wing [mailto:[EMAIL PROTECTED] > >>>>> Sent: Sunday, November 14, 2004 2:27 PM > >>>>> To: MyFaces Discussion > >>>>> Subject: Re: Back Button problems > >>>>> > >>>>> > >>>>> I don't think there is a way you coudl do this with javascript > >>>>> because when you hit the back button you aren't talking with the > >>>>> server at all, you are just going through the browser's cache. > >>>>> > >>>>> > >>>>> On Sun, 14 Nov 2004 08:45:08 -0700, Arinaya <[EMAIL PROTECTED]> > >>>>> wrote: > >>>>> > >>>>>> Ok that makes sense. > >>>>>> But is there any way to force JSF to refresh the View > >>> > >>> when a page > >>> > >>>>>> is loaded in the browser? > >>>>>> > >>>>>> Or is it possible to send a request automatically on > >>> > >>> page load if > >>> > >>>>>> the View is not synchronized with the current page? > >>>>>> > >>>>>> I think I could use javascript to do a form submit on page load, > >>>>>> but how would I check the current JSF View using > >>> > >>> javascript? Is it > >>> > >>>>>> possible? > >>>>>> > >>>>>> Thanks > >>>>>> > >>>>>> > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: Heath Borders-Wing [mailto:[EMAIL PROTECTED] > >>>>>>> Sent: Sunday, November 14, 2004 8:35 AM > >>>>>>> To: MyFaces Discussion > >>>>>>> Subject: Re: Back Button problems > >>>>>>> > >>>>>>> I tried the same thing. > >>>>>>> > >>>>>>> I don't know why client side state saving was throwing a > >>>>>>> NotSerializableException, but I know why you have to > >>> > >>> submit twice. > >>> > >>>>>>> > >>>>>>> Let's say you have two pages: A and B. If you submit a form on > >>>>>>> page > >>>>> > >>>>> > >>>>>>> A and navigate to page B, the view that JSF currently > >>> > >>> has stored > >>> > >>>>>>> is page B. So, if you use the browser's 'back' button > >>> > >>> to navigate > >>> > >>>>>>> to page A, JSF will take one request to synchronize the > >>> > >>> page and > >>> > >>>>>>> the view. Then the second request will be normal. > >>>>>>> > >>>>>>> I don't think that switching to client side state saving will > >>>>>>> change > >>>>> > >>>>> > >>>>>>> this behavior. > >>>>>>> > >>>>>>> > >>>>>>> On Sat, 13 Nov 2004 14:31:06 -0700, Arinaya > >>> > >>> <[EMAIL PROTECTED]> > >>> > >>>>>>> wrote: > >>>>>>> > >>>>>>>> Hello All, > >>>>>>>> I hope someone can please help me with this -- > >>>>>>>> > >>>>>>>> Currently when I navigate back to a form that has > >>> > >>> previously been > >>> > >>>>>>>> submitted, using the browser back button, I need to click > >>>>>>> > >>>>>>> the submit > >>>>>>> > >>>>>>>> button twice in order for the form to actually resubmit. The > >>>>>>>> first > >>>>> > >>>>> > >>>>>>>> click seems to reset the form, clearing any changes that have > >>>>>>>> been > >>>>> > >>>>> > >>>>>>>> made to input fields since navigating back to the form. > >>>>>>>> > >>>>>>>> We are currently using server-side state saving method, and > >>>>>>> > >>>>>>> I thought > >>>>>>> > >>>>>>>> this might be the problem, so I tried switching this > >>> > >>> to client, > >>> > >>>>>>>> but then the FacesServlet throws a > >>>>>>>> java.io.NotSerializableException. > >>>>>>>> > >>>>>>>> Has anyone had either of these two problems? > >>>>>>>> How can I get the browser back button to work? > >>>>>>>> Using MyFaces 1.0.7. > >>>>>>>> > >>>>>>>> Thanks, > >>>>>>>> Arinaya > >>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> -- > >>>>>>> If you don't have a GMail account, I probably have 5 invites. > >>>>>>> Just ask! -Heath Borders-Wing [EMAIL PROTECTED] > >>>>>>> > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> If you don't have a GMail account, I probably have 5 > >>> > >>> invites. Just > >>> > >>>>> ask! > >>>>> -Heath Borders-Wing > >>>>> [EMAIL PROTECTED] > >>>> > >>>> > >>>> > >>> > >>> > >>> -- > >>> If you don't have a GMail account, I probably have 5 invites. > >>> Just ask! > >>> -Heath Borders-Wing > >>> [EMAIL PROTECTED] > >>> > >> > > > > > > > -- If you don't have a GMail account, I probably have 5 invites. Just ask! -Heath Borders-Wing [EMAIL PROTECTED]
