10 Easy Steps for Creating Custom JSF Components

  1. Find out the standard HTML component that closely matches your required custom JSF component
  2. Write the component class that extends from the identified standard JSF component implementation. Override "getFamily()" method to return a "Family Name" for your custom component
  3. Write your custom validator class that performs required UI validations for your custom component. Your validator class implements "Validator" interface in JSF framework
  4. Include "addValidator(new YourValidator())" call in your component class.
  5. Write your Renderer class by extending "Renderer" class in JSF framework. Override "encode" (generate HTML for the component) and "decode" (interpret HTTP Request and set value to the component) methods based on your requirement.
  6. Create "faces-config.xml"
  7. Register your custom component class (created in step 2) in faces-config.xml with a unique "Component-Type" name.
  8. Register your custom Renderer class (created in step 4) in faces-config.xml with a unique "Renderer-Type" name.
  9. Create your custom Tag Handler class that extends "UIComponentTag" class provided by JSF Framework. Override "getComponentType()" and "getRendererType()" accessor methods. Make sure that the Type names returned by these two methods matches the names registered in faces-config.xml (Step 7 and Step 8)
  10. Create you Tag Library (TLD) for the custom Tag and associate Tag Handler (created in Step 9) class with the custom component tag.
Web World Moving to Client-Side UI Architecture

For many a years, I have enjoyed working on client-side UI applications especially on the Microsoft products. The outstanding feature that kept me interested in Visual Programming Applications was the ability of the client-side applications to successfully distinguish the presentation and the behavior of the UI components by using an event-driven programming model. Unfortunately, World Wide Web did not have that privilege to use such a distinction; reason being the Network traffic barrier that separates the event-handler, the Server from the Presentation at the Client Side, on The Browser.

That was when web world turned their attention to the art of scripting; to use client side scripts and hence to reduce the overhead of client-to-server and back network travel. Hence, came the days when HTML was sandwiched with JavaScript and VB Scripts. Presentation and the Behavior stuffed together. Web Designers who were previously “Creative Artists” then learned the art of scripting and begun to call themselves as “Web Programmers”. Web community could not draw a line of distinction between presentation and behavior yet.

Soon, problems started to surface. First, the application maintenance and porting became tedious. The task of identifying the problem routine from among the mark-up language and content and rectifying the issue turned out to be a nightmare. Portals introduced the concept of aggregation for content rendering making page designers and scripting artists to stretch their abilities to the extreme limits.

Things started looking better when Java community decided to organize itself using scriptless JSPs. Custom Tags and EL were quite effective. Struts Framework provided another useful alternative by moving the HTML validation to the Server Side. But still, bits and pieces of code remained in the JSPs that serviced component handling tasks.

JavaServer Faces was the revolutionary concept that came to the rescue of developers in the web world. Initial step was to clearly distinguish and define the roles in a typical web application development. Then, the fine-grained model of separating the presentation from the behavior was introduced by moving everything to the server side.