Scope/Life cycle of UIComponent tree on the server side

[kavithakaran kanapathippillai]

I am newbie to JSF. Could someone please help me on the following.
When a view, say VIEW-A,is requested for the first time, The restore view phase creates a UI component tree( call it COMPONENT-TREE-A) corresponding to VIEW-A and it's state is stored before it is renederd. And then when the user submit data using VIEW-A, the COMPONENT-TREE-A on the server side is restored.

1) Now say due to wrong data submitted, JSF returns the same VIEW-A to the user asking to fill all the fields in VIEW-A. Will JSF store the state of COMPONENT-TREE-A again before rendering the VIEW-A?

2) Say multiple clients( different browser sessions) are making first time request VIEW-A. Will JSF create seperate instances of Component tree corresponding to VIEW-A for each client?

3)Say multiple requests from the same client( Using tabs in Firefox) are made receive VIEW-A. Will JSF use just one instance of Component tree corresponding to VIEW-A?

4) when is the stored Component tree gets destroyed?



Thanks in advance

[Tim Holloway]

It's too early in the morning for me to actually comprehend all those questions properly, but here's the basic concept on UIComponent trees:

A UIComponent tree is constructed by compiling a view template. Each client gets a their own compiled UIComponent tree, since it not only contains information about display input and output, it also contains information about that particular user's view state and control values.

The compiled UIComponent tree can either be passed back and forth between client and server or it can reside on the server. Usually, residing on the server is the option you'll want. It's less network overhead and immune to client-side hacking. However, keeping the view on the server means that it takes up server resources, and the more clients, the more expensive that is.

The reasons for keeping the UIComponent tree around after the page has rendered (to HTML, usually) and sent to the client are twofold. First, and most importantly, because it contains information that will be used in JSF's postback processing. Secondly, because web clients typically support a "Back" button, and - depending on the client - that may trigger a re-rendering operation for a page previously visited.

UIComponent trees are not trivial, and, in fact, one of the advances in JSF2 was to reduce the overhead of UIComponent trees. But regardless of the JSF version, there is a mechanism in the server-side UIComponent mechanism that will discard UIComponent trees which are (hopefully) no longer needed. In cases where it turns out that the mechanism guessed wrong, you get a ViewExpiredException, which is simply the exception that JSF throws when you've requested a UIComponent tree that was discarded and no longer available.