Win a copy of Practical SVG this week in the HTML/CSS/JavaScript forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Viewstate stored in session and the values of input fields

 
Jorge Martinez
Ranch Hand
Posts: 41
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hy,

Many times I have read that JSF stores de view state in session and one of the things that are stored are the values of the form fields, right? But these input field values are not stored in session, I mean, they depend of the scope of the managed bean attached to the view. If I have a view and its attached to a view scoped bean with properties for the form fields, the values will dissapear if I go to other view because the bean is view scoped so I cant say the values of the form are stored in session, right?

Thanks
 
Tim Holloway
Bartender
Posts: 18422
60
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Actually, the View State can be stored on the server (I don't think there's any actual guarantee it's stored in a session) or it's passed back and forth in serial form between client and server (thus stored on the client).

Which form of storage is used will be determined by settings in web.xml.

The View State isn't holding the official property values and you shouldn't be coding stuff to pull values from it. What the View State is holding is work in progress, and unlike the actual value transfer done by JSF, these values are not guaranteed to be valid.
 
Jorge Martinez
Ranch Hand
Posts: 41
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ok. Lets put an example if I get it:

1. When I submit a form and it has validating errors, the reason I see the values filled again is because these values are stored in the view state, right?
2. Is there other case where I could get these values filled again from the view state and not from the backed beans?

Thanks
 
Tim Holloway
Bartender
Posts: 18422
60
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Unless you are customizing JSF itself, your sole concern with ViewState should be whether you define it to be client-held or server-held. Any application code that attempts to peer inside the ViewState, or (worse) modify it, is very perilous. It's likely to break at unexpected times and unexpected places, become totally obsolete when new JSF versions are released, and be virtually incomprehensible to ordinary JSF application programmers who might be called on to work with the app.

In short, consider it a "black box". The values that users type into a form will keep being echoed back to them until all values pass validation. At which point the lifecycle processor wll no longer short-circuit, but instead it will update the backing bean, fire the change listeners and related appendages, then invoke the action processor(s). After which, the Render Response lifecycle phase will prepare a new View and populate its form values from that View's Models (backing bean properties).

As I've said many times, JSF is a platform designed to work with POJOs and platform-independent techniques. Thus, the more JSF-specific code a webapp contains, the more likely it hasn't been optimally designed.

If being a wizard in the internals of JSF for its own sake appeals to you, or if you actually do want to implement your own version of JSF, there are technical implementation specs available as part of the J2EE standards docs. But "clever" exploitation of deep internal features in ordinary application code wouldn't get you promoted in my office.
 
Politics n. Poly "many" + ticks "blood sucking insects". Tiny ad:
the new thread boost feature: great for the advertiser and smooth for the coderanch user
https://coderanch.com/t/674455/Thread-Boost-feature
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!