UI Component
Renderer-Specific Class
Renderer Type
Syntax/JSP Tag
HtmlOutputLink
Link
<h:outputLink>
HtmlOutputText
Text
<h:outputText>
UIPanel
HtmlPanelGrid
Grid
<h:panelGrid>
HtmlPanelGroup
Group
<h:panelGroup>
UIParameter
null
*
<h:parameter>
UISelectOneBoolean
HtmlSelectBooleanCheckbox
Checkbox
<h:selectBooleanCheckbox>
UISelectItem
null
<h:selectItem>
UISelectItems
null
<h:selectItems>
UISelectMany
HtmlSelectManyCheckbox
Checkbox
<h:selectManyCheckbox>
HtmlSelectManyListbox
Listbox
<h:selectManyListbox>
HtmlSelectManyMenu
Menu
<h:selectManyMenu>
UISelectOne
HtmlSelectOneListbox
Listbox
<h:selectOneListbox>
HtmlSelectOneMenu
Menu
<h:selectOneMenu>
HtmlSelectOneRadio
Radio
<h:selectOneRadio>
UIViewRoot
null
<f.view>
* Source: The JavaServer Faces specification 1.1
** This component has no associated renderer.
C H A P T E R 1
s
T H E F O U N D AT I O N O F J S F : C O M P O N E N T S
16
For each combination of UIComponent and Renderer, there is a renderer-specific subclass,
or convenience class. A standard JSF implementation, such as the Sun RI or the MyFaces run-
time, comes with a set of HTML renderers (provided through the standard HTML RenderKit)
and a set of HTML renderer-specific subclasses, such as HtmlSelectOneRadio.
Renderer-Specific Component Subclass
In most cases, this subclass creates an instance of the component at runtime. As defined by
its name, this subclass provides access to renderer-specific attributes on a JSF component
such as style, disabled, tooltip, and so on--providing property getters and setters for all of
these component attributes. In conjunction with the binding attribute on the JSF JSP tag, this
subclass allows application developers to use JavaBean property setters to change renderer-
specific attributes on the component at runtime.
Although this does work and is a useful tool for prototyping, we recommend that, where
possible, application developers avoid modifying the renderer-specific attributes directly from
the backing bean application logic and instead use the behavioral superclass of the compo-
nent. If application developers use the parent class instead of the convenience subclass, they
have no need to modify the backing bean code when the JSF component changes to use a dif-
ferent renderer-specific component in the page definition, such as from HtmlSelectOneRadio
to HtmlSelectOneListbox. The backing bean code needs to change only when the behavioral
superclass also changes, such as changing from HtmlSelectOneRadio to HtmlSelectManyList.
This subclass is optional, but it is good practice to provide this subclass with the JSF com-
ponent, since sometimes application developers may like to use it for convenience, and for
component writers it is hard to know whether application developers will try to use this.