RichFaces 4 CDK | jQuery UI Calendar

Further incrementing the complexity over the input component we created previously, this time we will create a JSF calendar component. Being pragmatic OSS developers, we will leverage the existing javascript of the datepicker component from the jQuery UI project, and we'll see how well the RichFaces CDK lends itself to mapping JSF component attributes into javascript configuration options.

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

The Component Class
Starting again with the component class:

AbstractDatepicker.java

package ca.bleathem.richfaces.jquery.component;

import org.richfaces.cdk.annotations.*;

@JsfComponent(
        type = "ca.bleathem.richfaces.jquery.Datepicker",
        family = "ca.bleathem.Datepicker",
        renderer = @JsfRenderer(type = "ca.bleathem.jquery.DatepickerRenderer"),
        tag = @Tag(name="datepicker"))
abstract public class AbstractDatepicker extends javax.faces.component.UIInput {

    @Attribute
    public abstract String getDateFormat();

    @Attribute
    public abstract String getShowOn();

    @Attribute
    public abstract String getButtonImageOnly();

}

Here we see we are again extending the UIInput class, as we did with the Input component.  What's new is the introduction of some additional attributes.  The @Attribute annotation instructs the CDK that these abstract getter methods map to component attributes, and the CDK then takes care of wiring the attributes into the JSF state saving mechanism for us.

The naming convention of the attribute is alligned with jQeury UI datepicker options. This allows us to transparently pass the JSF component attributes through to the jQuery plugin, as we see in the Renderer below.

The Renderer
The renderer is again an xml file:

datepicker.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.jquery.renderkit.DatepickerRenderer</cdk:class>
        <cdk:superclass>ca.bleathem.richfaces.jquery.renderkit.DatepickerRendererBase</cdk:superclass>
        <cdk:renderer-type>ca.bleathem.jquery.DatepickerRenderer</cdk:renderer-type>
    </cc:interface>

    <cc:implementation>
        <input type="text" id="#{clientId}" name="#{clientId}" class="rf_jq_cal" value="#{getInputValue(facesContext, component)}" />
        <script type="text/javascript">
            <cdk:scriptObject name="pluginOptions">
                <cdk:scriptOption name="buttonImage" value="#{getResourcePath(facesContext, 'ca.bleathem', 'calendar.gif')}" />
                <cdk:scriptOption attributes="showOn dateFormat buttonImageOnly" />
            </cdk:scriptObject>
            jQuery(function() {
                $(document.getElementById('#{clientId}')).datepicker(#{toScriptArgs(pluginOptions)});
            });
	    </script>
    </cc:implementation>

</cdk:root>

Diving first into the cc:implementation of this renderer template, we see again an input element. What's new is the script tag following the input. This script tag get's compiled into javascript when the component renders. Using CDK xml markup, we build up the javascript object pluginOptions which we pass as a parameter to the call to the jQueryUI plugin.

The document.getElementById('#{clientId}') is a workaround for JSF's use of the ":" character in javascript IDs - this doesn't play well with jQuery. By first calling document.getElementById, we end up with an argument that is acceptible to jQuery. Notice the #{toScriptArgs(pluginOptions)} argument to the datepicker jQuery UI plugin. This initializes the datepicker plugin, with the JSF component attributes specified by the application developer.

From the cc:interface of this renderer template, we see that we are extending the class DatepickerRendererBase. This class is included below:

DatepickerRendererBase.java

package ca.bleathem.richfaces.jquery.renderkit;

import org.richfaces.renderkit.InputRendererBase;

import javax.faces.application.ResourceDependencies;
import javax.faces.application.ResourceDependency;

@ResourceDependencies({
        @ResourceDependency(library = "javax.faces", name = "jsf.js"),
        @ResourceDependency(name = "jquery.js"),
        @ResourceDependency(library = "com.jqueryui/css/ui-lightness", name = "jquery-ui-1.8.16.custom.css"),
        @ResourceDependency(library = "com.jqueryui/development-bundle/ui", name = "jquery.ui.core.js"),
        @ResourceDependency(library = "com.jqueryui/development-bundle/ui", name = "jquery.ui.widget.js"),
        @ResourceDependency(library = "com.jqueryui/development-bundle/ui", name = "jquery.ui.datepicker.js"),
        @ResourceDependency(library = "ca.bleathem", name = "calendar.gif")
})
public class DatepickerRendererBase extends InputRendererBase {
}

The DatepickerRendererBase class is again extending the InputRendererBase, and it is holding a number of @ResourceDependency annotations. These annotations ensure the appropriate resources are included on the page when we reference this JSF component. For us, these resources are the jQuery UI plugins necessary to get the datepicker component working.

Introducing an entire new class merely to hold the @ResourceDependency annotations may seem like overkill, but in any reasonably complex component, we will end up putting some renderer helper logic into this class file. There are times when the expressivity of Java works better than the declarativity of xml. We'll see some of this later in our blog series.

Finally, let's look at en example use of this component:

sample.xhtml

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
      xmlns:h="http://java.sun.com/jsf/html"
      xmlns:ui="http://java.sun.com/jsf/facelets"
      xmlns:b="http://bleathem.ca/test"
      >

<body>
<ui:composition template="/templates/template-jqueryui.xhtml">

    <ui:define name="title">Datepicker Sample</ui:define>

    <ui:define name="body">
        <h:form>
            <b:datepicker value="#{myBean.value}" dateFormat="yy-mm-dd" showOn="both" buttonImageOnly="true" /> <br />
            Input value: <h:outputText value="#{myBean.value}" /> <br />
            <h:commandButton value="Submit" action="null"/>
        </h:form>
    </ui:define>
</ui:composition>
</body>
</html>

When rendered, this looks like:

Screen shot

While this has certainly grown in complexity over our initial HelloWorld component, we've managed to keep our JSF component development DRY. We've leveraged existing, high-quality javascript components. We've also made use of the RichFaces CDK to wire the JSF configured component to the javascript object. Some additional work is required to continue mapping the jQuery UI datepicker plugin options into JSF component attributes, but the mechanism for this has been laid out, and completing the component will be quite straight forward (pull requests welcome!).

In my next CDK installment, we'll look at creating a layout based component, rather than an input component. Stay tuned!

Testing AS7 web apps over SSL

Here's a recipe I found useful for trouble-shooting a web-app over an SSL connection. The steps involved are to:

1. Set the server name/IP on each of the testing machines (both Windows and Linux)
2. Create a self-signed certificate for the server using the java-based keytool
3. Export the certificate for installation as a CA in the clients
4. Configure JBoss AS7 to use the certificate sotre

All the above steps are sufficiently simple, but each required it's own share of googling to get everything just right. This post is as much a set of notes to myself in the future, as it is a blog.

1. Setting the Server name

On your Linux testing machine, make sure the sure IP and name of your local server are in your /etc/hosts file:

127.0.1.1 bleathem-redhat bleathem-redhat.local

Do the same thing for you windows clients - that's right! Windows has a /etc/hosts file! See this wikipedia article to locate the file in your version of windows.


2. Create a self-signed certificate
Use the java keytool command to create the certificate store:

keytool -genkey -alias tomcat -keyalg RSA -validity 3650 -keystore server.jks

when asked for your "first and last name", answer with the fully-qualified domain name. For me this is bleathem-redhat.local.

3. Export the certificate
Export the certificate from the keystore you just created, again using the keytool command:

keytool -exportcert -alias tomcat -keystore server.jks -file as7.cer

Copy this certificate to your Windows clients, and install it as a certificate authority. I found this to be necessary, as IE9 is particularly nasty about dealing with "unofficial" certificates. Steps to do this are left as an exercise for the reader! (I don't feel like taking a bunch of windows screenshots.)


4. Configure JBoss AS7
In the standalone.xml configuration file of your AS7 instance, find the line:

<connector name="http" protocol="HTTP/1.1" socket-binding="http" scheme="http"/>

And add below it the lines:

<connector name="https" protocol="HTTP/1.1" socket-binding="https" scheme="https" secure="true">
    <ssl name="https" password="changeit" certificate-key-file="standalone/configuration/server.jks"/>
</connector>

This will configure your AS 7 instance to use your newly created certificate store on it's SSL enabled port. The default https port for AS7 is 8443.

And there we have it!  A fully functional SSL/https enabled environment for testing our web apps!

RichFaces 4 CDK | Input Component

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:

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:

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.

RichFaces 4.1.0.M2 Release Announcement

The Richfaces 4.1 milestone releases are trucking along. With M1, we had a focus on changes surrounding project infrastructure, and the introduction of some new components. Now with M2 we see updates to the core, and a stabilization of both the new components and the framework as a whole.

jQuery Upgrade

We built the RichFaces 4 components using jQuery for DOM manipulation. Given the degree to which the we rely on jQuery, upgrading it is a "big deal". In order to ensure none of our components break during this milestone release, both our QE and Dev teams have been busy tending to our test infrastructure. The benefit of shipping with the latest jQuery is that it provides better compatibility to application developers wishing to leverage cutting edge jQuery plugins, or integrate with other component libraries.

IE9 support
As part of our extensive testing of our platform, we noticed a number of compatibility issues with Internet Explorer 9 running in strict or normal mode. We isolated this as an upstream issue, and will work with the Mojarra team to patch the underlying problem. In the mean-time, the issues can be worked-around if you run IE 9 in compatibility mode.

Stabilization of the new components
The new components introduced in M1 have benefited from further development, and constructive user feedback (thanks!).

rich:editor
The Editor has several new features, but the most valuable is the integration with the standard RichFaces styling scheme. Further details are available in Lukas’ blog post.

rich:notify
Notify Messages have been better integrated into the RichFaces ecosystem, allowing them to consume Client-Side Validation messages. The Notify Stack was also refactored - this is where one configures the location and orientation of messages.

rich:pickList
The Pick List has picked up ordering capabilities in the target list, making it now a viable replacement for the older listShuttle from RichFaces 3. In addition, the Pick and Ordering Lists have exposed more events, allowing for applications to better hook into their behavior.

Face-to-Face
A fair chunk of time during the M2 sprint was spent by the team in a face-2-face meeting, where our world-wide development team came together to discuss the future of the project. Stay tuned for updates along these lines, as we distill our ideas and engage the community for feedback to collectively define our project vision and future.

Forward: M3 and mobile
As always, we've taken care of a number of bug fixes with the M2 milestone release. However, the upcoming M3 release is when we will buckle down and focus on taking care of stabilizing the platform as a whole, and fixing as many bugs as we can, particularly in the mobile space. To help us better identify where we would best be spending out attention, please get on Jira, and vote for the issues that are important to you.

RichFaces 4 CDK | Hello World

This is the first technical post of my CDK series. Starting real simple, we'll create a component that produces a hello world output. "Why start with a hello world? Isn't that a little cliche?". Well indeed it is, but it is by far the best way to point out the fundamental pieces of the CDK, and how they together. We'll build a strong foundation in our understanding of the CDK, on which we can build more interesting components in future posts.

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

The Component Class
To start, we need a component class. The component class itself will be generated by theRichFaces CDK. However we do define a base class from which the generated class will extend. We'll see why this is the case when we get to more complex components. But for now, let's start with this base class:

AbstractHello.java

package ca.bleathem.richfaces.hello.component;

import org.richfaces.cdk.annotations.*;

@JsfComponent(
        type = "ca.bleathem.richfaces.hello.Hello", 
        family = "ca.bleathem.text", 
        renderer = @JsfRenderer(type = "ca.bleathem.hello"), 
        tag = @Tag(name="hello"))
abstract public class AbstractHello extends javax.faces.component.UIComponentBase {

}

Here we have an abstract class annotated with @JsfComponent. This annotation marks the class as a CDK class, and will be consumed by the CDK pre-processor. The CDK uses the attributes of the annotation to construct the necessary classes, and the necessary xml configuration. Creating JSF components is verbose, but we don't have to worry about the verbosity - the CDK takes care of it for us!

Let's look more closely at the @JsfComponent annotation, and the meaning of each of it's attributes. I'll start by pointing out that the annotation supports many more attributes, but we are only covering here the bare minimum required to get a simple hello world component created.

type

the value of the type attribute is how JSF identifies out component. It will be used in the generated faces-config file, and in the generated xml taglib file.

family

the value of the family attribute is used by JSF to recognize "like" components. We'll get into details of this in future posts. This attribute is in fact optional, and the value can be generated by naming conventions. However, I prefer to specify it explicitly.

renderer

the value of the renderer attribute is used to match our component to an appropriate renderer. We'll create the renderer next!

tag

the value of the tag attribute will be the actual facelet tag that we use in our facelet files.

The last aspect of out component class that I want to point out is the "extends UIComponentBase" part. Every JSF UI component must extend this class, or one of it's descendants. We'll be able to save ourselves alot of work when we get to more complex components, by judiciously choosing the right class to extend.

The Renderer

Next, let's look at the JSF Renderer:

hello.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.hello.renderkit.HelloRenderer</cdk:class>
        <cdk:superclass>javax.faces.render.Renderer</cdk:superclass>
        <cdk:renderer-type>ca.bleathem.hello</cdk:renderer-type>
    </cc:interface>

    <cc:implementation>
        Hello World! (from a RichFaces CDK component)
    </cc:implementation>

</cdk:root>

If you are familiar with JSF Component development, you may be surprised to see that our Renderer is not a java class. On the other hand, you may find that it looks quite similar to a JSF 2 composite component. It has a "<cc:interface>" section, and "<cc:implementation>" section, both of which are analogous to the facelet file of a composite component. In fact, you can prototype your components as composite components, then migrate to CDK components when you find you need the extra flexibility the CDK provides.

As we did for the component class, let's dissect the cdk tags found in our renderer template.

<cdk:class>

this is the name of the JSF Renderer class that will generated.

<cdk:superclass>

the class that will be extended by our generated JSF Renderer class. Here we are explicitly stating the default for reference when we get into more complex components.

<cdk:renderer-type>

this is how JSF identifies our Renderer. It will be used in the generated faces-config file, and in the generated xml taglib file.

And there we have it, a JSF Component, and it's associated Renderer! -- err almost. There is one final piece missing. We need to specify a name space for our component - the namespace that will be used on facelet pages that refer to our components. Fortunately, the CDK also makes this easy for us. All we need is a package-info.java in the java package of our component:

package-info.java

@TagLibrary(uri="http://bleathem.ca/test",shortName="testLib")
package ca.bleathem.richfaces.hello.component;
import org.richfaces.cdk.annotations.TagLibrary;

Here you can see the @TagLibrary annotation that specifies the namespace of our component.

Now we can build a jar, include it in our application, and use our hello world component! Go ahead and run the build. If you are curious, take a look in the target/generated-sources folder. There you'll see all the JSF classes and xml files that the CDK generated for us. Those are all classes and xml files we would have had to write ourselves if we weren't using the CDK.

Well, a hello world JSF component - not really useful... but there is more coming! The next entry in this series will use the CDK to create an input component, and from there we'll get into some more sophisticated components!

In closing, I want to add that the CDK is incredibly flexible, and there all multiple ways the above component could have been put together. I'm sticking to what I think is simplest, most clear, and most extensible.

Seam Faces Community Hack Night

Seam Faces Community Hack Night!

This week's Seam 3 Community hack night is centered around Seam Faces.  This is a great chance to mingle with some CDI/JSF developers on IRC, and get your fingerprint into the Seam Faces DNA!  Whether you have your own itch you want to scratch, a long-standing bug you want to see resolved, or implement a new feature altogether, we've got plenty of low hanging fruit ripe for the picking!

In preparation for the hack-a-thon, I've given the Seam Faces JIRA issues a once-over.  I've collected a number of issues that I feel are ready to be resolved into a JIRA version calles 3.1.0-Tracking.  I'd like to highlight a few of the issues here, and perhaps motivate you to come join us at the hack-a-thon to resolve some of them!

SEAMFACES-122: Type safe navigation!
Of all the low-hanging fruit, this one has to be the juiciest!  Implement a Navigator utility class to map the @ViewConfig enums to their String @ViewPattern's for use in JSF navigation.  Imagine using your IDE to find all usages of one of your views - type safety FTW!

SEAMFACES-26: Implement global protection against XSRF attacks
Help the community of Seam 3 developers make their apps more secure by implementing a scheme to protect against XSRF attacks!  Think hidden form field, view state and a random number generator.

SEAMFACES-28: ObjectConverter and EntityConverter
Let's resurrect the Entity Converter from Seam 2.  The EntityConverter is persistent context aware, and will use the primary key of your JPA/Hibernate entities to handle JSF Conversion.

SEAMFACES-150: Refactor BeanManagerUtils to make use of Solder's BeanManagerLocator
Are you aware with the Seam Solder API?  Want to learn more about how to wield this powerful tool?  Here's a refactoring that will surely get you more comfortable with how to use Solder.

SEAMFACES-6: s:debug
This issue is very well documented in JIRA, and just needs someone to put the pieces together.  What a great tool to add to your arsenal once complete!

SEAMFACES-185: Add support for activating beans based on the JSF project stage
Christian Kaltepoth has done a great job with this issue, but we've got a tough nut to crack.  How to parse the web.xml before the Servlet Context is available?  If you got some ideas here, help us bring this one across the finish line.

SEAMFACES-184: Extend an example to demonstrate events propagation features
Familiar with Seam Faces, but don't feel up to hacking on the core?  How about writing an example application, to demonstrate some of Seam Faces' cool features?

SEAMFACES-152: Create documentation for using Seam Catch in Faces
Another great way to contribute to the project, without writing a single line of code is to contribute docs!  Help other Seam 3 devs figure out what you already know!

These are just a few of the issues ready to be solved during the hack night.  So drop by on IRC, and give us a hand squashing some issues.  At the very least, I'm sure you'll have fun!

RichFaces 4 CDK | Introduction

A new blog series

Having recently dived head first into the RichFaces 4 Component development Kit (CDK), I thought it would be useful to share the knowledge and experience I've gained.  Over the next few weeks, I am going to put out a series of blog posts giving some examples of how to use the RichFaces CDK.  Hopefully by the end of this series, we will have written some interesting components and left you with the urge to write your own JSF components using the CDK!

Before I get into specific examples, I’d first like to motivate the series by describing what exactly the CDK is and the problems that it solves.  If you already know all about JSF components, and you want to get straight into using the CDK, skip this blog post! - the rest of the entries in this series will deal purely with implementation details.

What is the RichFaces CDK anyway?

JSF was designed to make components easy to consume.  The syntax is very html-like, and EL makes it easy to bind components to backing beans.  However, writing JSF components has traditionally not been very accessible.  With the number of classes that one has to create and wire together, along with a requirement for detailed knowledge of the JSF API, components were typically left to third party component suites, like RichFaces, IceFaces and Apache. Things were improved drastically with the release of JSF 2.0, and it’s support for composite components.

Composite components let the user build JSF components purely in xhtml - without requiring any lines of Java.  This is a fantastic improvement, as developers can build their own re-usable components that encapsulate a fair amount of complexity and keep their applications DRY. An overall bonus indeed! While composite components achieve a lot, the mechanism falls short when it comes to creating full-fledged JSF components.

The concise and non-java nature of composite components that makes them so appealing, is also their biggest limitation.  Oftentimes one needs additional expressivity not available in EL, or one needs to tap further in to the JSF lifecycle.  Thus in JSF 2, the component suite providers find themselves once again writing components in Java, to be able to take advantage of the rich APIs that JSF provides.
This is where the RichFaces CDK comes in.  The RichFaces team provides the CDK as a means for developers to write JSF components with many of the simplifying advantages of the JSF 2 composite components, but also with the full power and flexibility provided by the JSF component APIs.


JSF Components simplified with the CDK

To understand how to use the CDK, one first has to understand how JSF components are put together.  At the end of the day, JSF components are built out of Java classes, and the CDK is simply an effective means to generate those classes.

To build a JSF component, one starts by extending the UIComponent class.  This class defines the attributes and API of your component and is responsible for hooking into the JSF state saving mechanism.  While you could put your rendering code into this component class itself, you’re better off putting that rendering code in a separate Renderer class.  You’ll also end up writing a TagHandler class to couple the Render and component.  And should your component fire FacesEvents, well you’ll need to implement additional interfaces and provide more classes.  Lastly you’ll need to register these classes in the faces-config.xml and provide a taglib.xml file.  Now there’s a mouthful!

The CDK simplifies this all for us, by generating a lot of the above code.  All we need to create when we use the CDK is a component base class, and an xhtml file to define the rendering behaviour called the “Renderer template” .  This Renderer template is designed to build on the JSF 2 composite component mechanism, so if you can build JSF 2 composite components, you’re already half-way there!

With the component base class, the Renderer template, and the annotations that couple them, the CDK is able to generate the rest of the required files for us.  There is nothing sub-standard about these generated classes - they are full-fledged JSF components in every way!  In fact, much of the RichFaces 4 component suite is built using the CDK!

There is a lot of detail to cover in how to write the component base class, and the accompanying Renderer template.  I’ll begin covering these details in my next post, where we will write a “Hello world” JSF component using the CDK.  But if you can’t wait for my post, feel free to dive into the RichFaces CDK docs.