JSF was designed to accomodate this behavior-- having multiple buttons,
complex interactions, etc-- just wrap everything in one form.
lightbulb432 wrote:
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?
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="...."/>
