Win a copy of Production-Ready Serverless (Operational Best Practices) this week in the Cloud/Virtualization 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
  • Liutauras Vilda
  • Bear Bibeault
  • Jeanne Boyarsky
  • paul wheaton
Sheriffs:
  • Junilu Lacar
  • Paul Clapham
  • Knute Snortum
Saloon Keepers:
  • Stephan van Hulst
  • Ron McLeod
  • Tim Moores
  • salvin francis
  • Carey Brown
Bartenders:
  • Tim Holloway
  • Frits Walraven
  • Vijitha Kumara

State in JSF  RSS feed

 
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?
 
Bartender
Posts: 20562
120
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Welcome to the JavaRanch, Nilimamla!

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.

JSF's core ("h") tag library simply presents the basic HTML controls and no HTML control can be expanded or collapsed. However some of the third-party extension libraries do support controls like that. Depending on how they're constructed and what tag options the View Template designer used, the control state may be kept entirely client-side (via internal JavaScript code) or it might be passed back to the server to become part of the ViewState and thus the Component Tree. It all depends on how the custom tag was designed.
 
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
https://www.kickstarter.com/projects/paulwheaton/better-world-boo
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!