RE: Problem with RESTORE_VIEW

[Bieringer, Dominik]

Okay. I will take a look at the specification. Thx.   Dominik   From: Simon Lessard [mailto:[EMAIL PROTECTED] Sent: Thursday, November 09, 2006 11:42 To: MyFaces Discussion Subject: Re: Problem with RESTORE_VIEW   Check the <form> tag in your page, it has an action attribute. And yes the URL is used, dynamic content is always based on the value of some request parameters, they're the source of JSF magic. For a more detailed description of the phase I suggest you look at the specification found at : http://java.sun.com/javaee/javaserverfaces/download.html near the end of the page (section JavaServer Faces v1.1 Specification Final Release). The section fof the specification you want ot read is 2.2.1 Regards, ~ Simon On 11/9/06, Bieringer, Dominik <[EMAIL PROTECTED] > wrote: Hi Simon,   Thx for your answer… I've just checked the code which get's generated by JSF, here is a part of it:   document.forms['mainBrowse:browseContent:browseTreePage:browseTreeMain:browseTreeMain'].submit();   So where is the ID of the current view? Maybe I am missing something?... I don't think that the URL is used for determining which view to restore either, because that would not be possible if you have dynamic content for the same URL which changes on requests…   Dominik   From: Simon Lessard [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 09, 2006 11:26 To: MyFaces Discussion Subject: Re: Problem with RESTORE_VIEW   Hello Dominik, JSF knows what view to restore from the requested URL. Behind the scene, it's always a form.submit that get executed and the form always point on its viewId. So, when the user press the back button and get a page from his cache, he also get the cached form that included an action on P2, not on P3. So the user fill fields as wanted and/or press directly on a link that would reach P4 which submit the form with some POST parameters that JSF interpret on P2 viewId. I hope I was clear, but considering it's 5h24 currently, I cannot be too sure about that =P Regards, ~ Simon On 11/9/06, Bieringer, Dominik <[EMAIL PROTECTED]> wrote: Hi all,   I've some problems with the restore view mechanism JSF provides. First of all I like to summarize what I think happens in this phase:   JSF tries to restore the component tree of the page that did the request….. this means: You are on page P1, clicking on a link which redirects to P2, JSF does the following: RESTORE_VIEW: Restore component tree of P1 … RENDER_RESPONSE: Clear the UIViewRoot and set a new one, which contains components of P2 You are now on page P2, clicking on a link which redirects to P3, JSF does the following: RESTORE_VIEW: Restore component tree of P2 … RENDER_RESPONSE: … Create component tree of P3   I hope that's correct ;). Please correct me if I'm wrong. I want to know what happens in the following case:   A user was on P1, was on P2, and is now on P3 (as described above)…. Now the user uses the back button of the browser, and is on P2 again (The page has been retrieved from cache). Now the user clicks on another link, which redirects him to P4. Here is what I think happens in the JSF phases in this case: RESTORE_VIEW: Restore component tree of P2 … RENDER_RESPONSE: Clear UIViewRoot and create new component tree of page P4   Here are my questions: Is this correct? How does JSF know which component tree to restore? Is it possible to detect if a request comes from a cached page? Is there something like a unique ID which gets written to every page, so that I can store them in the session and check if a page has already been submitted?     Thx in advance, Dominik