With our last component, we saw how we could output some simple text with a custom JSF component created with the RichFaces CDK. Let’s increment the complexity, and see how we can create a component that accepts input. Again, the goal here is to highlight how the important features fit together, and to leverage as much of the plumbing work as possible from the RichFaces CDK.

If you are interested in following along in your IDE, you can get the code below on github.

The Component Class

In a similar approach to our Hello World component, we’ll start with the component class for our Input component:

div=. AbstractInput.java

package ca.bleathem.richfaces.input.component;

import org.richfaces.cdk.annotations.*;

@JsfComponent(
        type = "ca.bleathem.richfaces.input.Input",
        family = "ca.bleathem.input",
        renderer = @JsfRenderer(type = "ca.bleathem.input"),
        tag = @Tag(name="input"))
abstract public class AbstractInput extends javax.faces.component.UIInput {

}

This looks pretty similar to the component class for the Hello World component, with an appropriate changing or type, family, renderer and tag. One significant change to take note of is the base class for the component. Notice how we are extending the UIInput class. This allows us to leverage the value holding and state saving that has already been built into this component. No matter what kind of UI you want to build for your component, you will almost always want to store a single value (we’ll discuss select many components in another post). So extending UIInput is generally a good idea.

The Renderer

The corresponding renderer template for our input component is:

div=. input.template.xml

<?xml version="1.0" encoding="UTF-8"?>

<cdk:root xmlns="http://jboss.org/schema/richfaces/cdk/xhtml-el" xmlns:cdk="http://jboss.org/schema/richfaces/cdk/core"
    xmlns:c="http://jboss.org/schema/richfaces/cdk/jstl/core" xmlns:cc="http://jboss.org/schema/richfaces/cdk/jsf/composite"
    xmlns:javaee="http://java.sun.com/xml/ns/javaee">

    <cc:interface>
        <cdk:class>ca.bleathem.richfaces.input.renderkit.InputRenderer</cdk:class>
        <cdk:superclass>org.richfaces.renderkit.InputRendererBase</cdk:superclass>
        <cdk:renderer-type>ca.bleathem.input</cdk:renderer-type>
    </cc:interface>

    <cc:implementation>
        <input type="text" name="\#{clientId}" value="\#{getInputValue(facesContext, component)}" />
    </cc:implementation>

</cdk:root>

Again, this looks pretty similar to the template for the Hello World component. The key difference being the Renderer superclass, and the html markup in the cc:implementation. By extending the RichFaces InputRendererBase class, we save ourselves from having to write the logic to decode and invoke the validators for our component. Again, this is something we will want to do for many of the components we write.

The html markup is also rather simple. By giving the input element the name of our component ID, we are indicating which form component should be decoded when the component is processed. When authoring a component with a complex UI, you will often make this input element a hidden input type, to store and submit your value while not interfering with your UI. We’ll see more of this in later entries of this CDK series.

I’ll also add that the package-info.java file described in the Hello World entry is still required, if you don’t already have one included in your jar.

And that’s our input component - again done as simply as possible. The next entry will wrap an existing jQuery UI component, showing how the CDK is an effective means to leverage the work others have already put in to authoring complex javascript components.