In JSF Life Cycle i am trying to understand this statement
If the request for the page is an initial request, the JavaServer Faces implementation creates an empty view during this restore phase and the lifecycle advances to the Render Response phase, during which the empty view is populated with the components referenced by the tags in the page
So what is the Empty View in restore phase and what does it mean to say Empty view is populated with the components referenced by the tags in the page
Trying to understand JSF statemangement especially with viewstate ,component tree state,component tree datastrucutre.
After going through some articles i have this understanding
Viewstate---> object that has only values entered by users for an element with in view.For example for username--john,password--abcd, viewstate stores jhon and abcd (Is this correct?) .Viewstate doesnot store component tree structure of page?
component tree state---> component tree state and view state ,these words are same and refer to the values entered by user in a view
component tree data structure---> this is run time representation of view that is objects are created for each control with UIViewroot as object.
Also viewstate and component tree data structure are stored with in JSF(by default in session?).
Also if there are 1000 customers.
And say if there is a view/screen username and password . Is it true that JSF creates 1000 component tree data structure objects.
Is it not possible to use one component tree data structure object for all 1000 customers
An "empty view" is simply a form before any user data has been entered. Since JSF sends the same form back and forth possibly many times, it builds support data structures to reduce the work required.
So when you first request a page, the Restore View lifecycle step creates the internal structures that will be used to render the actual web page. Since JSF form controls have associated backing bean properties, the backing beans are located or constructed and their "get property" methods are used by JSF to obtain the initial form control values. This then goes to the Render Response lifecycle step will invokes a plug-in renderer to product the actual output. In almost all cases these days, the renderer is an HTML renderer, but JSF was designed to support other output formats as well.
The Component Tree is constructed as working storage used by JSF to indicate what components (including forms and controls) will be read and rendered and what their spatial relationships are. You don't normally access it directly - and generally shouldn't - but it is possible to construct or modify the view structure by manipulating the Component Tree. The Component Tree serves as primary input to the Render Response phase, since it models the HTML (or whatever) that will be generated by the renderer. Once the Render Response phase is done, the Component Tree can be plundered for View State information and discarded.
The View State is essentially the Component Tree collapsed down for when when a request is not being processed. Depending on the option you have set in web.xml, it can be stored either on the client side or in the server. The default is server-side, which is more secure, uses less network bandwidth, but consumes more server storage resources. The View State is used on the next incoming request to reconstitute the Component Tree as part of the Restore View phase.
If 1000 users are all actively working with the same View, then yes, there will be 1000 View States. This is necessary since the View State contains the information that each user is working with, and since they cannot share the View, each user has the possibility of totally unique form values. There may not be 1000 Component Trees, however, since the Component Tree only exists during the actual Request/Response cycle and not during the time between requests when the user is viewing and/or modifying the form data.
And, just for the record, using JSF for login screens is a horrible thing to do. Use the JEE standard security system. It's much more secure and all it needs is HTML or JSP forms, not JSF Views.
Finally, although the Component Tree structure is fairly well-documented, the ViewState is not. Its format is entirely dependent on the vendor of the webapp server and on the version of the server and can change radically without notice. That's OK, since it's only intended for internal use by the webapp server and should never be accessed by application code.
An IDE is no substitute for an Intelligent Developer.