RENDER_RESPONSE Phase

The RENDER_RESPONSE phase is also responsible for saving the state of the component.
When I first read this, I thought, should not the method that invokes this save the state of the component? However, this will not allow us to implement saving the state on the client. Because when we save the state on the client, the state must be saved before the response stream is closed (actually before the response is totally rendered).

Be careful to not delete/modify any components in the saveState method.
If we change the state of components in the saveState method, we risk jeopardizing the integrity of the component.

Should all HTTP requests always be to the component that was last rendered?
I am not sure... need to think about it???

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.