I would like to understand "State" in JSF. Does State mean only the values entered by end user in the view displayed?Or it has a broader meaning?
What does ViewState mean then?
What is UI Component tree. Basically what i understand is UIComponent tree is set of objects on server that represents a view on browser in Tree Strucutre format.Is that correct.?
So does UIComponent tree also has state of its own.?
Say for example there is a component that has Expand(+) and collapse(-) button.User can click either + or -. Say on Clicking +,there is form displayed to user and user entered some data in form.In this case what is State and where it is stored? where form data is stored and where the state data when user clicks Expand to Collapse is stored.?In UIComponent Tree ?
And does UICompnent tree store form data that is entered by user?
Also Backing beans has form data which are scoped,then what is ViewState?What viewstate contains?and difference between viewstate and data in backing beans.
Basically i have this confusion on what exactly State is and different types of state in JSF when a request goes through lifecycle.
So what is difference between UIComponent Tree State, BackingBean state, ViewState?
Is there any link where i can go through or can some one share their inputs on this?
Also if there is a form and it has its corresponding UIComponent tree.And if there are 100 users accessing form.Then do we have 100 component trees as data entered by user will be different?Or there will be single component tree and a separate StateObject where the data is stored for each user and given to UIComponent tree?Then what is that StateeObject?
Java Enterprise Edition defines 4 scopes for the server-side containment of javabeans used by the web application: Page, Request, Session and Application. Page scope is not supported by JSF. Request scope is supported, but because JSF operates on a postback mechanism, Request scope is almost entirely useless. Session Scope provides per-user application state objects. Application Scope provides per-application state objects (shared between all users).
JSF version 2 added some additional scopes. Internally they're actually built on the 4 primary JEE scopes, but JSF adds some useful functionalities to create new JSF-specific functions. The most commonly used additional scope is View scope.
As I said, Request scope is almost completely useless because of how JSF's postback mechanism works. The lowest level that works properly with postbacks is Session scope, but the problem with using Session scope for per-page data is that once you've navigated from one page to another and no longer need the backing information for the old page, it still remains, cluttering up the webapp and consuming server storage. And JSF doesn't actually support a mechanism for deleting Session scope objects. You have to cheat if you want to get rid of the clutter.
View Scope eliminates that problem. Once you navigate to a new View (page), the View scoped objects from the previous page are automatically destroyed.
OK, now for the Component Tree. The Component Tree, like the FacesContext, does not have an independent existence. The Component Tree has 2 primary purposes: 1) to provide a support infrastructure to assist the JSF Controllers in validating form data values and 2) to act as the blueprint that the JSF renderer will used to output the actual response data back to the client (usually HTML).
Except when JSF is actively processing a user request, the Component Tree doesn't exist. Instead, there's an undocumented data structure called the ViewState that contains the information that the master Controller (the FacesServlet) uses to re-create the Component tree as part of its Restore View processing phase. Depending on what option was defined in the application's web.xml file, the ViewState may be passed back and forth between client and server or it may reside permanently on the server. The default is to keep it on the server, which has less network overhead and is more secure, but which requires one ViewState per active JSF user. Storing the ViewState on the client side is more network overhead and less secure (anything stored on the client is easy to hack), but doesn't require per-user server storage space.
Just to clarify: the server may actually keep a cache of ViewStates for a user's web pages, but there will be only one Component Tree, it will only exist for the View being processed, and as soon as the server has sent the response back to the client, this Component Tree will be destroyed.
When it comes to destroying a civilization, gas chambers cannot hold a candle to echo chambers.
The fastest and most reliable components of any system are those that are not there. Tiny ad:
global solutions you can do at home or in your backyard