Reading the JSF spec

Application.getDefaultRenderKit() should (in my opinion) never return null. [pg 231]

JSF component id and clientId

JSF components have a clientId as well as an id.

The id of a component is the id that it chooses to give itself. This may be specified or can also be auto generated by the JSF framework.

The clientId is the id that is transmitted to the web client. For a component, it's clientId is the clientId of the closest parent that implements NamingContainer followed by the JSF seperator char followed by the clientId of this component.

A little code snippet that implements getClientId().

click on the image to get a better view

JSF phase events

The phaseId property of ActionEvent indicates which phase of the request processing lifecycle, this event should be processed.

The broadcast method is called after each phase (where events can be processed). By default it processes all events that have the same phaseId as that of the current phase.

Hence, if we want an event to be processed in a particular phase, we should set the phaseId of the event to the appropriate value, so that the broadcast() method will process it at the correct time.

Do we invoke broadcast manually, or is it invoked when we call super.whatever() in the appropriate phase?

JSF rendererType

The rendererType to use for rendering a JSF component really exists as a property in the component itself. We can call setRendererType(String rendererType); to set the rendererType.

When the component is being rendered, the appropriate renderer will be selected based on the rendererType. The runtime knows which renderer is mapped to a rendererType, because we map it in faces-config.xml. However, it can also be set in code, I believe.

When we use JSP tags to represent JSF components, then the tag handler class can also have a method getRendererType(); which returns the rendererType for that component. This is convenient because the JSF runtime will query the tag handler for the rendererType and will set it in the corresponding JSF component.

Some common component properties

Most components support a certain common set of properties. Among them are 'value', and 'binding'.

value - The component's current local value. Can be literal text or a value binding expression
binding - A value binding expression that associates this component to a backing bean property

If the 'value' property is a value binding expression, the value entered by the user in an input component will also be updated in the appropriate backing bean property, if the value passes all validations.

On first glance, the difference between 'value', and 'binding' is not very clear. I think (need to verify), 'value' (when used with a value binding expr) is used to transfer the user's input into a backing bean property, whereas 'binding' is used to associate a component with a backing bean property so that the backing bean can manipulate the component within code (Hence the type of the backing bean property must be the same as the type of the component).

JSF Request Processing Lifecycle

The JSF request processing lifecycle has 6 phases. Each events are generated after some of the phases. The listeners that handle these events can either skip the remaining phases and proceed strsight to the last phase "Render Response" or they can render the response themselves.

Validation in JSF

Validation in JSF can happen at three levels: in the component, in the backing bean, or in a custom validator.

Component Level - For simple 'required/not required' type of validations. Also the code is very component specific. It is within the component and cannot be reused by other components.

Backing Bean Level - This should be used for business requirement type of validations. The validations are specific to the particular business requirements within which the component is being used. These validations also cannot be reused by other components.

Validators - These are reusable validators for validating field sizes, value ranges, etc. We can reuse these validators accross components. JSF comes bundled with some default validators, and we can also create our own custom validators.