myfaces-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Kitching <>
Subject Re: Problem with RESTORE_VIEW
Date Thu, 09 Nov 2006 20:01:22 GMT
Hi Dominik,

Bieringer, Dominik wrote:
> 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:
> 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?
>           o 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?

Yes, I believe that what you described is 100% correct.

Back-button support is not really part of the JSF spec; what happens 
when the back button is pressed is implementation-specific. However both 
Sun's RI and MyFaces do provide support for this.

When using client-side caching, it happens automatically, because after 
the user clicks "back" then submits a form, the old saved component tree 
gets submitted back to the server and hence the old component tree gets 
When using server-side caching, the last N component trees are stored in 
the http session, where N defaults to 20 but can be configured in the 
web.xml (sorry, can't remember the key).

The code that looks up the view is in which 
delegates to (method restoreView). For 
server-side state, this clearly gets a "sequenceString" which is used to 
determine which of the cached component trees to use. 
HtmlResponseStateManager.getTreeStructureToRestore looks in three 
*request parameters* for data:
* jsf_viewid
* jsf_tree
* jsf_tree_64
so I would guess that these fields are automatically inserted into every 
form in the html page when using server-side state saving. I can't check 
this as the work I'm currently doing uses client-side state saving.

However I don't see how to piggyback "page resubmit detection" on top of 
this, ie to detect whether this has actually happened or not.

The Shale library ( provides a bunch of useful 
utilities for JSF, including a <token> component that I think does this 
sort of checking:

However there are any number of JSP tags around to do this (just 
google), and I don't see why they can't be used together with JSF, ie 
why a JSF-specific solution is needed.



View raw message