Re: Problem with RESTORE_VIEW

[Simon Lessard]

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