More JSF

For a web application, all objects held in the application scope must be handled in a threadsafe manner; because all users and all requests have access to the objects in this scope, it's very likely that more than one thread will access the same object. Objects in the session scope must also be threadsafe, because they are shared by all requests from the same user. If the user makes parallel requests, e.g., by submitting the same form over and over without waiting for the response, making requests from multiple browsers tied to the same session, or requesting pages that contain references (e.g., frame references) to other pages that modify session scope objects, a session scope object's state can be corrupted.

When you use JSP as the presentation layer technology for JSF, you don't use the JSF API at all for creating and rendering components. Instead, you use the custom actions from the JSF custom tag libraries to say which components you need, and the tag handlers use the JSF API to create and render the corresponding component objects for you.

The first action element in the page, , is very important. The combination of the components that make up a specific user interface screen is called a view in JSF. A view contains an instance of the javax.faces.component.UIViewRoot class. This class is a nonvisual component type that acts as a container for all the other components in the view. Components representing UI widgets, such as input fields and buttons, are children of the UIViewRoot and can have children of their own. Together, the components form a tree, with the UIViewRoot at the top. The action element represents the UIViewRoot component and you must make sure it encloses all other JSF action elements in the page; otherwise, they aren't included in the view.

Note that there's a one-to-one relationship between a JSF view and an HTTP response. Hence, you must use only one element in the JSP page. A JSP page can, as you may know, include other JSP pages dynamically. Such included pages represent subviews in JSF, and are represented by an element.

The next JSF action element, , represents a form component, acting as a container for input components that hold values that should be processed together. Within the element

The element names for all these actions are composed from a component type name and renderer type name. The core JSF components represent pure behavior and know nothing about how they are represented on a screen. This task instead falls on renderers associated with each component, making it possible to represent the same type of component in different ways. Take < h : inputText >, for example. It represents an input field component, i.e., a component type that holds a value that can be changed by the user. Such a component can be rendered in different ways. The < h : inputText > action associates the input component with a text renderer, which renders the component as an HTML < input > element with the type attribute set to text. Another action element named < h : inputSecret > associates an input component with a renderer of type "secret," which renders the component as an HTML < input > element with the type attribute set to password.

< h : commandButton >
component Type : command
Renderer type : Button

< h : commandLink >
component Type : command
Renderer type : Link

< h : panelGroup >
component Type : panel
Renderer type : Group

< h : panelGrid >
component Type : panel
Renderer type : grid

< h : selectOneMenu >
component Type : selectOne
Renderer type : menu

Most component types can be combined with more than one renderer type, and each valid combination is supported by an action element following the naming convention.

So why doesn't the element name follow the same convention? Because the only renderer type for the form component type is the form renderer. To avoid action element names like , JSF uses an abbreviated element name when the component type and the renderer type have the same name