This week's book giveaway is in the Jython/Python forum.
We're giving away four copies of Hands On Software Engineering with Python and have Brian Allbey on-line!
See this thread for details.
Win a copy of Hands On Software Engineering with Python this week in the Jython/Python forum!
  • 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 all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Bear Bibeault
  • Knute Snortum
  • Liutauras Vilda
Sheriffs:
  • Tim Cooke
  • Devaka Cooray
  • Paul Clapham
Saloon Keepers:
  • Tim Moores
  • Frits Walraven
  • Ron McLeod
  • Ganesh Patekar
  • salvin francis
Bartenders:
  • Tim Holloway
  • Carey Brown
  • Stephan van Hulst

View State in JSF  RSS feed

 
Greenhorn
Posts: 23
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello ,

while going through JSF,i have got some questions on viewstate in JSF


What is View State in JSF? What it contains?
This is what i understand after reading some articles
There are two types of state: Application state and view state.  
To serve its purpose every application needs to maintain some sort of state. From a JSF developers perspective, application state is held in managed beans. These are associated with a certain scope, e.g. request or session scope.
Here by the word application state i understood it as data entered by users or data shown in form.
If application state is held in backing/managed beans then what viewstate contains?
And what purpose it serves?

Is ViewState same as UIViewRoot,which just hold memory of the components only in session.


 
Bartender
Posts: 20107
101
Android Eclipse IDE Linux
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In a Model/View/Controller environment, there are typically 2 states: The Model State and the View State. The Model State ("Application State") holds the "official" values of the controls. The "View State" holds their values as seen by the user.

In a real-time MVC environment, these two states would be more or less identical, but since JSF is HTTP-based (sending and receiving data in batches), they can be out of sync. Note that Controllers are the synchronizing mechanisms between Model and View and therefore have no state of their own.

In fact, there are two View States. One is the state of the View in the client (the web page) and one is the state that JSF thinks the View is in. The client view state is initialized to the JSF View State, but is changed every time the user modifies a form control value. When the form is submitted, the JSF View State is updated to contain the changed values from the client view state. The JSF lifecycle processor then validates these state values, and if the values are all valid, JSF will then inject these updated values into the Model, thus synchronizing the two States.

Conversely, when logic changes the JSF Model, the lifecycle processor updates the View State, uses this updated state to render the view (into HTML, usually), and sends the rendered view back to the client.

So the View State is basically the Component Tree in its inactive form.

The actual structure of the View State internals is not something you should be looking at unless you are creating or maintaining JSF itself. It can change without notice and there are far easier and safer ways to work with View State data.

The View State itself can be stored either on the client or on the server. The default is to keep it on the server. This is more secure and reduces network overhead. You would keep View State on the client if you were not as worried about security or bandwidth, but wanted many, many concurrent clients, since each user's View States take up RAM (and there can be several of them at a time as the user moves from View to View).
 
Shekar Chandu
Greenhorn
Posts: 23
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello Tim,

Thanks for replying.

I have few more question on View State

1) From your statement  There are typically 2 states: The Model State and the View State.
The Model State ("Application State") holds the "official" values of the controls. The "View State" holds their values as seen by the user.


This is my understanding
So for example
<INPUT type="text" name="firstname">
     As per above example "Application State" is blank
<INPUT type="text" name="firstname" value="Jhon">
     As per above example "View State" is Jhon

2)     Also From first 2 lines of your statement i understood View State as just data entered by user.
But below statement again relates View State to the strucutre of page that gets created as Tree object and stored in session

So the View State is basically the Component Tree in its inactive form.

So is it like ViewState means component tree that is runtime represtation of JSF components as objects along with initial values entered by user.
Can you please correct if iam wrong.

3) And in this statemetn So the View State is basically the Component Tree in its inactive form.
 what does inactive form mean?A form with no initial values or default values

4)Also in your statement but since JSF is HTTP-based (sending and receiving data in batches), they can be out of sync ,with out submitting a single request to server how can they be differernt?

5)Also in your statement  there are two View States. One is the state of the View in the client (the web page) and one is the state that JSF thinks the View is in.. can you please elaborate on state that JSF thinks the View is in.
  How come JSF know the view with out submitting a first request by user
     

 
Tim Holloway
Bartender
Posts: 20107
101
Android Eclipse IDE Linux
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm probably going to have to answer this in reverse order.

First, however, make sure you understand the different states of the JSF lifecycle. https://docs.oracle.com/javaee/5/tutorial/doc/bnaqq.html

Shekar Chandu wrote:5.    How come JSF know the view with out submitting a first request by user



There is no View until the user makes a request. The initial View is the response to that request. Unlike raw HTML, you cannot post form data to a server without having first having the form, since the JSF meta-data (View State) must be included as part of the posted data.

Shekar Chandu wrote:4.    with out submitting a single request to server how can they be differernt?

As I previously said, there is no View, and therefore no View State until a request has been made. The JSF will also instantiate any missing Model objects (and therefore Model State) when the request is made, so both are in sync when the web page is first displayed.

Shekar Chandu wrote:3.    what does inactive form mean?

JSF is like Enterprise JavaBeans in that things have both active and inactive forms. A webapp, unlike a regular application, is not a continously-running program. A webapp is only "running" when it is processing a user request. And since requests are based off threads in the server's thread pool, that means that at any given time, a webapp may have 100 instances "running" (for 100 different users), or 0 instances running. Each instance has its own unique state data (user session), and that includes both the JSF infrastructure (including View Component Tree) and the JSF Model objects. But once the request has processed and the response has been sent, the webapp reverts to an inactive state (from that user's point of view) until another request is made by that user (if ever).

In the inactive state, Request-scoped Model objects are discarded and the View Component Tree is deactivated. What that means is that the system may collapse the View Component Tree into a form that takes up less memory, by compressing objects and/or discarding data that isn't needed while inactive. That means that the essential View State is preserved, but it may not be in the form of a Component Tree. The system can then send the collapsed View State to the client - which it will do if your web.xml configuration sets client-side view state, or it may keep it in RAM or write it out to disk until it is needed again. Session-scoped Model objects may also be dumped from memory to disk to reclaim RAM - that's why Session-scope objects must be Serializable.

The JSF Restore View lifecycle step is responsible for re-creating the component tree from the saved View State.

Shekar Chandu wrote:2. But below statement again relates View State to the strucutre of page that gets created as Tree object and stored in session



I think you are confused here. The Component tree isn't blindly copied to the Model - or "session", as you called it. The Component tree is working storage for the lifecycle processes. It holds incoming form values, but the form values will not be posted to the Model UNLESS all values in the submitted form have been proven valid. Even one invalid value aborts the process. Therefore you can never have an incompletely updated Model. The Component tree is where the data values to be validated come from. It's also what's compared to the Model to determine whether or not to fire a valueChanged event.

Think of the Component tree like it was your kitchen table and you're doing a craft project. You can't just keep your glue, supplies, and unfinished work on the table all day long (well, I do, and I get yelled at for it!). So if you're a well-organized person you might have a basket to pack it all into when you're not working. That basket is the saved View State.

Now start/resume work on your project. You unpack the basket (View State) so that everything is handy (Component Tree, Model) and you go to work. When you're done, you discard the rubbish (Request Mode Model Objects and Component Tree temporary work areas) and re-pack the basket. Now you can put the basket in a cupboard (disk file or other persistent storage). You can even transport the basket to a different table and work (which is basically how clustering functions).
 
Those who dance are thought mad by those who hear not the music. This tiny ad plays the bagpipes:
RavenDB is an Open Source NoSQL Database that’s fully transactional (ACID) across your database
https://coderanch.com/t/704633/RavenDB-Open-Source-NoSQL-Database
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!