• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

ViewState and SessionState

 
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello All

Iam working on a  JSF Project and trying to understand ViewState.

Here by the word state i understood it as  values for controls entered by user.So ViewState means collection of all values entered by a user for a single page.
So when we make a first request to a page,JSF will create a UIComponent tree corresponding to the view that is runtime instance of all components in a tree strucutre with empty state since its a first request.
So for second request to same page(Postback) UIComponent tree is updated with form control values that is values entered by users. Here JSF engine will use its internal controller to get values from backing/managed beans tied to components and update the UIComponent tree along with state(values entered by user) for each control.

So where is the view state over here? Because JSF is updating UIComponent tree.


Is it another object that gets created along with UIComponent tree on server(that is on session) or is it created by JSF during initial request and sent back as client response and that viewstate id is being refered when the users tries to go back to that page.

If yes then both ViewState and UIComponent State on server hold same data? And JSF uses ViewState to just update the  UIComponent tree State if there are differences between the two provided user has modified values for same page?

And also where is viewstate stored on server or on client machine (In both client side and server side state management).

And also any pictorial representation of viewstate and UIComponent State would really help me in understanding the basics.

Also if there are 10 views in my application ,will there be 10 ViewStates and also 10 UIComponentTrees created on server that is on session per single user?

Thanks in advance
 
Saloon Keeper
Posts: 27762
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Welcome to the JavaRanch, Reddy!

As it happens, this has been a recent topic of discussion. See this thread: https://coderanch.com/t/695840/java/View-State-JSF

As I mentioned there, the Component Tree only exists while the FacesServlet is actually processing a View. The rest of the time it's collapsed into ViewState. The Restore View JSF lifecycle step is responsible for re-creating the Component Tree from the ViewState - and for creating the initial Component Tree.

JSF keeps a cache of ViewStates as you travel from View to View. So there could be 10 ViewStates, one (or none) Component Tree. This cache can expire, which triggers the ViewExpiredException.

ViewState is not conceptually attached to HttpSession. Although the default is that ViewStates are stored on the Server, an override setting in the web.xml file can cause the View State to be passed back and forth between client and server repeatedly rather than remaining on the server.
 
Reddy Jatin
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello Tim,

Thanks for replying back.

So it means that  Component Tree is request scoped irrespective of whether backing/manged beans of components are session/application scoped.Once the request is served back to the user UI-Component is removed from server.
So if there are 3 views A,B,C then there will be 3 viewstates ,one each for A,B,C views.Then for each view a hidden field is set into the form by JSFengine as below

<input type="hidden" name="javax.faces.ViewState" id="javax.faces.ViewState" value="7249534836608350716:­2454600105753096458" autocomplete="off" />

So when the same page is posted back to server,then even this hidden filed goes to server,in turn JSF will use this viewstate  value to recreate component.

Here my understanding is that if viewstate is passed as hidden parameter on each page/view submit then why do we need to store it in http-session. Or
why it should be passed as hidden parameter if viewstate can be stored on session.And since session is unique for each user,it should be easy to retrieve viewstate from session object and thus recreate component.
Actually confused between viewstate sent as hidden parameter or stored in session?
And also here viewstate just contains values enters by users only not the runtime instance of UIComponent.

Can you please let me know.

Also i will go through the link you have shared

Thanks in advance
 
Tim Holloway
Saloon Keeper
Posts: 27762
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
As far as an application programmer is concerned, the ViewState structure and id do not exist. They are there only to help JSF do what it needs to do and if someone came out with a better way tomorrow, they might very well be radically altered or even disappear entirely. A JSF h:form isn't intended to be processed by non-JSF code nor is it expected that JSF should process an ordinary HTML form with a "view state" hidden in it, since there may be context you don't know about.

The ViewState preserves the state of the View, but it is not the View itself, and in JSF what you should be working with is the View. In most cases, even the View Component Tree is ignored by application code, since it's only used for directly manipulating the View and mostly you should let JSF itself do that.

I don't know - or care - where a server-side ViewState is preserved. For all I need to know, it's not in an HttpSession (and probably shouldn't be!), but in an Application Scope variable or even in an internal JSF infrastructure static variable. The fact that on the JSF form it's an ID instead of a long complex collection of characters implies to me that the ID is actually just an arbitrary key into a collection of ViewStates somewhere. Also, it's obviously not the only way to reference a ViewState, since, for example, a commandLink also can restore a View. As can ordinary JSF View Navigation.
 
Reddy Jatin
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello Tim,

Thanks for replying back.


So JSF Framework stores the state of a component in ViewState object and it is maintianed internally by JSF
Say for example if i define a managed bean **A** tied to a component with session scope.
Then even after page is rendered,managed bean **A** is still in session object.
Even ViewState object corresponding to rendered page is also maintianed internally by JSF.

What is difference between states stored in both Managed Bean and ViewState?
So is it like same state  stored in 2 different objects?

Is it like JSF uses managed beans to update viewstate on a intial request and on Postback request, it is versa.

Also i am going thru some links to understand  JSF lifecycle in depth to completely understand relation between state held in ManagedBean(used as model by component) stored on a scope,viewstate and UIComponent tree

Thanks in Advance
 
Tim Holloway
Saloon Keeper
Posts: 27762
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
HttpSession is an object created on demand - and not before. It would be possible to create a JSF webapp that had no session scope objects at all, and therefore no HttpSession. Furthermore, the traditional way to log out of JEE container security was to destroy the HttpSession, which by implication destroys all of the objects stored in session scope.

However, the Application and Session scopes maintain application state for the remote user between Http requests. And, since these are the same object containers are regular JEE uses, their state is available to non-JSF application components - JSF is not a greedy framework and for certain tasks, it's better to use a non-JSF servlet or JSP, so it's useful that they share the same state space.

The ViewState is just the working storage for component tree persistence and form data in transit. It isn't used by the application code, only by JSF internally. When you submit a form, the JSF Restore View lifecycle step re-constructs the View Component Tree for that form's View and posts the incoming data into the Component working storage for the form's values. However, JSF will not post form data values to the backing bean unless each and every form value passes validation. If even one form value is invalid, JSF will bypass the posting and action steps, add an invalid field message to the request's JSF Messages, and post the form back to the user, allowing the messages to be displayed according to how the user specified them on the View Template. And, incidentally, update the ViewState so that future renderings will remember the last thing the user id, and not lose input even when the input is invalid. The user is then allowed the opportunity to correct the invalid values and re-submit the form.

Once the submitted form has passed all control value validations, then and only then JSF will post the updated values to the backing beans and invoke the action method. The action method then returns with a navigation value or null, which indicates what View will restored and rendered back to the user.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic