×
☰ See All Chapters

JSF UI Component Tree (View)

When a user makes an initial (non postback) request to view the registration form, an hierarchical UI components are instantiated on the server (using getChildren( ), getParent( ) and some other methods) that exactly represent what is viewed in the browser. Such hierarchical structure is known as Component tree. The UI component tree is also known as the View.

Rendering this hierarchical representation is done by calling a cascading set of  methods of UI components on each component that emit the appropriate markup for each respective component to the client.

UIComponent class has getChildren( ), getParent( ) methods. getChildren( ) returns a List of child UI components.  getParent( ) method is to access its immediate parent component. Since UIComponent  class is a Super class of all UI component classes, getChildren( ), getParent( ) methods are inherited to all UI component classes.

Once the UI component tree is in memory, it is updated to reflect any changes in the client between requests, such as new values in input fields or programmatic changes written to access and manipulate any properties of the components. In general, during each new request (postback), the UI component tree is constantly being altered with new values and settings based on the change in state of the UI in the client as changed by the end user.

jsf-ui-component-tree-0
 

All UI component classes are present in javax.faces.component package.

Whatever the thing that is displayed on browser, there must be a component tree for that which is displayed on browser. Whatever may be happening to component tree in server, either updating or creating new one, there must be ready component tree for which is displayed on screen. Component tree reflects what is displayed on screen.  

Class UIViewRoot

  • A class present in javax.faces.component package. 

  • UIViewRoot is the UIComponent that represents the root of the UIComponent tree which means it serves as the root of the component tree. 

  • Stores the unique view identifier of a view (UI Component tree) 

  • Stores the Locale used in localizing the response being created for view. 

  • Stores the render kit identifier of the RenderKit associated with view. 

In what basis view id is created and stored?

The view ID is the context relative path of the view file. E.g. /foo.jsp or /foo.xhtml. The ViewHandler implementation is responsible for creating it and storing it in UIViewRoot.

For every incoming request, viewid is extracted from the request URI by the underlying HttpServletRequest object by its getPathInfo() or getServletPath() methods, depending on whether the FacesServlet itself is mapped with prefix pattern (/faces/*) or suffix pattern (*.jsf) respectively.

When JSF needs to navigate to a new view as per a <navigation-case> in faces-config.xml, then the new view ID is simply extracted from URI and a new UIViewRoot is created by end of invoke action phase. Otherwise JSF just goes back to the same view as the previous request was originated.

Does view id created for the each JSP/facelet  one view ID?

Yes, every view has its own unique identifier, while updating a view  , new viewRoot object will be created, and newly created  view id is stored in viewRoot object.

How view ids are passed to render the response? Is it passed in the request parameter?

They are stored in UIViewRoot object. The ViewHandler implementation just calls getViewId() during the renderView() method.

What is a viewstate in JSF?

In JSF, there is a viewstate associated with each page, which is passed back and forth with each submits. The reason for the viewtate is that the HTTP is a stateless protocol. The state of the components across requests need to be maintained. The viewstate can change in between requests as new controls like UIInput can be added or modified. The view state is divided into two parts.

Part 1: Structure of the components
Part 2: Defines the state of the components. For example, enabled/disabled, input values, checked/unchecked, selected item, etc.

 


All Chapters
Author