RichFaces 4.0 Components Development Kit

This article is part of RichFaces JSF 2.0 migration

Although JSF 2.0 has a new declarative components, it seems too simple for a complex components ( like Tree, data tables and so on ) development. Also, it is still necessary to generate special getters and state saving-restore methods, add/removeListener methods, custom tag handlers and so on. The main purpose for the CDK is speeding up RichFaces components development, while it also could be convinient public tool for the third-party component developers.

Minimum of files.

In the perfect situation, component developer has to write two files only: Abstract component class that implements component functionality and JSF renderer template for visual representation. The CDK has to generate all necessary stuff ( concrete component class, renderer-specific component class, renderer class, faces-config.xml file, tag handler class and taglib file ).

Coding by convention

To avoid a lot of similar configuration elements, CDK uses its own RichFaces CDK naming conventions for classes, components and tags. Component developer may omit default values.

Configuration

The initial CDK project has been developed to create JSF 1.1 components, there were no faces-config extensions and JDK 5 annotations. Now, we can migrate to the modern features.

Instead of proprietary XML configuration the new version should use standard faces-config.xml with additional information in the <*-extension> tags like Mojarra components generator does:

    <property>
      <description><![CDATA[
          A mutable List of the child components associated with
          this component.
        ]]></description>
      <display-name>Child Component List</display-name>
      <icon/>
      <property-name>children</property-name>
      <property-class>java.util.List</property-class>
      <property-extension>
        <tag-attribute>false</tag-attribute>
        <read-only>true</read-only>
      </property-extension>
    </property>

 

As all modern XML and Faces-config editors have XML Schema support, these extensions have to be defined in the separate namespace and have its own schema. CDK can use JAXB library to marshal that configuration into XML model. To avoid repeated parts for identical elements, these elements can be extracted into separate files and included using XInclude.

Annotations. In spite of JSF 2.0 has annotations for JSF components, renderers and so on, it seems better to use proprietary CDK-specific annotations:

  1. Using component annotations in the abstract class is not possible, because framework can crash in attempt to check these classes.
  2. Standard annotations has no CDK-specific information.

Renderer Template

The main purpose for renderer template language was close a gap between HTML design and Java code, because it is very hard to convert complex enougth HTML code into the sequence of ResponseWriter calls and such code become unmaintable. The JSF 2.0 composite components has a different purpose as tool to combine existing components into reusable templates, but RichFaces project works on lowest level. Because of these differences it is not possible to use VDL-only tags for the renderer template language, but current syntax should be rewritten to use standard tags where possible.

The current CDK template compiler relays on RichFaces RendererBase class methods. That dependency should be removed.

Implementation tasks:

Generator project

  1. Reorganize 'pom' files according with the RichFaces 4.0 Build System
  2. Refactor component generator and renderer template compiler.
  3. Migrate CDK generator from DOM/digitester XML parsers to the JAXB .
    1. ??? Change default compiler level to the JDK 1.6 that includes JAXB 2.0 in the box ???
    2. Use XML schema for config files.
    3. Use XInclude for standard attributes
  4. Add CssParser support to compile CSS files as JSF renderers ( it is necessary for Skin feature optimization )
  5. Read Java class annotations for configuration information. Use standard JSF annotations where possible. XML configuration should have higest precedence.
    1. parse sources by qdox for JavaDoc comments ???
  6. Use Jboss EL implementation instead of Sun RI for the Renderer class compiler.
  7. Use FreeMarker template language instead of Velocity.
  8. Generate extended information for faces-config.xml
  9. ??????? remove ant task from the CDK or extract that into separate project.

Maven-cdk-plugin

  1. Convert 'assembly' mojo into Maven @aggregator, to elimenate requirements for separate 'assembly' project.
  2. Use prexus components where possible.
  3. Remove obsolete 'ERROR' log messages.
  4. Check source files for changes to avoid unnecessary generation.

Maven-javascript-plugin

  1. Add simple css files aggregation in addition to .xcss processing

maven-resource-dependency-plugin

  1. Generate static stylesheet content, using staging server from Jsf-test project.

 

Brainstorming ( unsorted thoughts )

 

  1. Using JSF 2.0 annotations instead of propietary XML format for component description. Additional anntotations should be introduced for non-standard metadata ( component attributes, documentation ). The XML files still be used for backward compatibility and reusable information like common pass through attributes.
  2. Generate component code compatible with JSF 2.0. It should use StateHelper instead of custom save/restore state, implements BehaviorHolder when necessary, pass Default values to StateHelper.eval method.
  3. Generate behaviors and behavior renderers.
  4. Add support for JSF 2.0 system events.
  5. Geterate Tag Handlers compatible with JSF 2.0 composite components.
  6. Convert JSP-based Renderer template language into JSF 2.0 VDL. In addition to XML format append CSS language to generate custom stylesheets for skinnability.
  7. Generate resources annotations for component JavaScript and CSS files.
  8. Make generated renderer independent from a base class, to do CDK library-independent.
  9. Build Assembled Library-wide and application-specific JavaScript and CSS files. Generate static stylesheets for required skins therefore these files could be served as static content.
  10. Generate automated tests for components and renderers.
  11. Develop set of functions to support current CDK capabilities (e.g. clientId).
  12. Optimize generated code. Use RI approach ( handleAttribute method ) for fastest access to common pass-through attributes.
  13. Generate XML Schema which could be used in IDE editors instead of tag library.
  14. Generate I18N resource bundles to use with UIComponent#getResourceBundleMap() method.