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: http://www.nabble.com/javax.faces.ViewState-hidden-field-tf2864080.html#a8014700 Sent from the My Faces - Dev mailing list archive at Nabble.com.
