13.2 Using Other Custom Classes

In the next chapter, we'll look at how to develop custom components in addition to custom renderers. Custom renderers and components are, however, not the only types of classes that you can plug into JSF. As I've mentioned before, pretty much everything in JSF is pluggable. You can replace the default ActionListener, NavigationHandler, VariableResolver, PropertyResolver, ViewHandler, and StateManager implementation classes. If a custom version of any of these classes has a constructor that takes an argument of the same type, JSF uses that constructor and passes in the previously registered instance as the argument. This makes it easy to provide a custom class that implements only some of the methods and delegates the rest to the previous instance. I'll show you an example of how to do this for a custom ViewHandler in Chapter 15.

A custom VariableResolver can be used to add implicit EL variables, such as an implicit variable named now that holds a java.util.Date instance for the current time. A custom PropertyResolver can add support for custom properties or data types not supported out of the box, such as a pseudo-property named ids for objects of type UIComponent to hold a java.util.Map with all children keyed by their IDs. This would make it easy to access components by their ID in a JSF EL expression, e.g., #{view.ids.form.ids.input} would access a component with the ID input nested within a component with the ID form.

Custom ActionListener and NavigationHandler classes can implement more sophisticated strategies than the default versions, which may be useful for integration with an application framework like Struts. A custom StateManager can fine-tune the state saving mechanism specifically for your application. We'll look at how to provide alternatives to JSP for creating views with custom ViewHandler classes in Chapter 15. The APIs for all these classes are straightforward, so if you need to use a custom version, you can read up on what to do in Appendix D.

You can even replace all factory classes, to provide replacements for all the core infrastructure classes, i.e., FacesContext, Application, Lifecycle, and RenderKit, and all standard components, validators, and converters. See Appendix D and Appendix E for details.