Page History

...

When learning JSF, there's nothing quite like looking at a real implementation.

...

• getRenderer shows how a renderkit instance uses the component's component-family and renderer-type to look up a map to determine the renderer class to be used for that component. Note also that only one instance of each specific renderer class is ever created; a renderer instance is expected to be stateless (and threadsafe) and is used to render all instances of the associated components. The renderkit's map is configured in code for the built-in types, and any META-INF/faces.config files found in the classpath can add extra entries to the map for a specific renderkit via:

...

...

javax.faces.webapp.UIComponentTag:

...

• Method createComponent takes a String component-type, and looks up its component map to find a Class object then calls class.newInstance on it. The component map is configured in code for the built-in types, and any META-INF/faces-config.xml files found in the classpath can add extra entries to this via:

...

• The other methods of this class are worth studying for more advanced purposes; this is where a lot of JSF customisation can occur.

...

• Methods processDecodes, processValidators, and processUpdates shows how form data becomes model data through a process of conversion and validation. For most components, This is where the real work mentioned above in org.apache.myfaces.lifecycle.!LifecycleImpl occurs during the Apply Values, Process Validations, and Update Model phases. Note that data starts in a form, is loaded into a submitted value field on the component, is converted to a local value field on the component, and is copied into the backing bean. Many conditions affect the outcome of this process, such as rendered state, required state, immediate state, conversion errors, and validation errors. Wiki Markup {scrollbar}