myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Kienenberger" <mkien...@gmail.com>
Subject Re: javax.faces.ViewState hidden field
Date Fri, 22 Dec 2006 01:45:42 GMT
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

On 12/21/06, Jacob Hookom <jacob@hookom.net> wrote:
> 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="...."/>
> >>
> >>
> >>
> >
> >
>
>

Mime
View raw message