javax.faces.ViewState hidden field

[lightbulb432]

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.

What determines whether a table has this hidden field or not?

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?

[Jacob Hookom]

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

Post by lightbulb432
What is the purpose of the hidden field named javax.faces.ViewState, and how
- 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.

Post by lightbulb432
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.

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

[lightbulb432]

Oh, you can put one h:form around the entire page? What if on a page you had
a login form, a sign-up for mailing list form, and a couple more...if you
put one form around the whole thing, is it still possible then? (Would the
only downside be that you'd have a lot more request parameters -- many of
which would be empty -- than you otherwise would have?)

Would that even work, or would the validators on the components from, say,
the mailing list form break the whole form when you were trying to submit
only the login form -- because it's all one big form now?

Post by Jacob Hookom
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

Post by lightbulb432
What is the purpose of the hidden field named javax.faces.ViewState, and how
- 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.

Post by lightbulb432
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.

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

[Jacob Hookom]

JSF was designed to accomodate this behavior-- having multiple buttons,
complex interactions, etc-- just wrap everything in one form.

Post by lightbulb432
Oh, you can put one h:form around the entire page? What if on a page you had
a login form, a sign-up for mailing list form, and a couple more...if you
put one form around the whole thing, is it still possible then? (Would the
only downside be that you'd have a lot more request parameters -- many of
which would be empty -- than you otherwise would have?)
Would that even work, or would the validators on the components from, say,
the mailing list form break the whole form when you were trying to submit
only the login form -- because it's all one big form now?

Post by Jacob Hookom
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

Post by lightbulb432
What is the purpose of the hidden field named javax.faces.ViewState, and how
- 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.

Post by lightbulb432
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.

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

[Mike Kienenberger]

Actually, the one downside of a single form is that it doesn't
accomodate independent validation sets. A validation error on your
mailing list form could very well break your login form.

The immediate flag can handle trivial cases, but not complex ones.

The ADFaces, Trinidad, and MyFaces Tomahawk sandbox subform tries to
handle this issue better.

This is probably one of the better pieces of documentation on it.

http://www.oracle.com/technology/products/jdev/htdocs/partners/addins/exchange/jsf/doc/tagdoc/core/subform.html

Post by Jacob Hookom
JSF was designed to accomodate this behavior-- having multiple buttons,
complex interactions, etc-- just wrap everything in one form.

Post by lightbulb432
Oh, you can put one h:form around the entire page? What if on a page you had
a login form, a sign-up for mailing list form, and a couple more...if you
put one form around the whole thing, is it still possible then? (Would the
only downside be that you'd have a lot more request parameters -- many of
which would be empty -- than you otherwise would have?)
Would that even work, or would the validators on the components from, say,
the mailing list form break the whole form when you were trying to submit
only the login form -- because it's all one big form now?

Post by Jacob Hookom
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

Post by lightbulb432
What is the purpose of the hidden field named javax.faces.ViewState, and how
- 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.

Post by lightbulb432
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.

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

[lightbulb432]

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?

Post by Jacob Hookom
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

Post by lightbulb432
What is the purpose of the hidden field named javax.faces.ViewState, and how
- 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.

Post by lightbulb432
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.

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