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="...."/>
