myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From lightbulb432 <>
Subject Re: javax.faces.ViewState hidden field
Date Thu, 21 Dec 2006 20:47:21 GMT

I was reading the 1.2 spec and saw the following line:

"The separation between tree structure and component state is now a
recommended implementation detail." 

Is it that line which explains the removal of two different structures - the
"tree structure" and "component state" (e.g. jsf_view_64 and jsf_tree_64)
and replacement with only one centralized structure - javax.faces.ViewState?
They essentially combine everything into that one field instead of two now?

Jacob Hookom wrote:
> JSF 1.2 standardized on the identifier: javax.faces.ViewState, previous 
> versions of JSF 1.1 (myfaces and RI) each had their own identifiers 
> which caused difficulties for component developers
> lightbulb432 wrote:
>> What is the purpose of the hidden field named javax.faces.ViewState, and
>> how
>> does it differ from the following hidden fields:
>> - jsf_view_64
>> - jsf_tree_64
>> Also, I noticed some sample HTML outputs from JSF, and they had multiple
>> javax.faces.ViewState hidden fields throughout the page. I also noticed
>> each
>> hidden field was on a separate table (i.e. no table had more than one
>> javax.faces.ViewState), and that each occurrence of the hidden field had
>> exactly the same value. Finally, I noticed that some tables on the page
>> had
>> this hidden field and others did not.
> Any component has the option of rendering the ViewState, traditionally 
> this is done at the start or tail of an h:form's rendered output.  Some 
> developers still put in multiple/separate h:forms in a page, forcing the 
> ViewState to be rendered within each form/scope.  A common practice is 
> to always put a single h:form around all of your content.  This can be 
> done easily if you use templating languages like Facelets where all of 
> your pages use one parent template that has one h:form around everything.
>> What determines whether a table has this hidden field or not?
> It's up to the components you use for the most part, except the the 
> enforced case of h:form.
>> I was just amazed by the huge inefficiency in having to transfer 3x the
>> hidden form field data (when each hidden field value is so large as it
>> is)
>> when they all have the exact same value! Would this be a good case to use
>> server-side state saving, because the bandwidth not doing so would eat up
>> would be huge, right?
> I'd be surprised what component would be rendering the page state 
> multiple times if not multiple h:forms in the page.  Since 
> javax.faces.ViewState is now a standard identifier, components with 
> JavaScript logic for postback (ala AJAX) could easily pull out the 
> ViewState from that one DOM source in the page instead of requiring a 
> separate render.  There are outlining issues with repeated 
> javax.faces.ViewState nodes in the page and sharing the same identifier 
> (DOM no-no), but we can get around this by rendering:
> <input type="hidden" name="javax.faces.ViewState" 
> id="javax.faces.ViewState" value="...."/>
> <input type="hidden" name="javax.faces.ViewState" 
> id="javax.faces.ViewState0" value="...."/>
> <input type="hidden" name="javax.faces.ViewState" 
> id="javax.faces.ViewState1" value="...."/>

View this message in context:
Sent from the My Faces - Dev mailing list archive at

View raw message