RichFaces 4.1.0.M3 Release Announcement

The RichFaces 4.1 Milestone 3 release is now available for download. Further building on the new components and framework improvements introduced in the M1 and M2 releases, M3 brings it all together with an improved showcase - featuring a demonstration of the mobile compatibility of the RichFaces 4 component set. Along-side improvements to resource handling, and enhancements to the push component, we’ve fixed a number of bugs and issues, as voted by you - our user community!

Showcase - Going Mobile

The showcase as seen on mobile
devices (using device detection)

The showcase has received some attention in this release. First and foremost we’ve demonstrated the mobile compatibility of the existing component set with the addition of some simple css and javascript resources (using a well vetted approach).

The mobile showcase in RichFaces is a an initial mobile effort, focusing on making the existing RichFaces components work within mobile browsers. While not a full-blown set of mobile components, we’ve tweaked the framework as necessary and put forward the mobile showcase as an example of how you can make your existing RichFaces applications mobile-friendly with the current RichFaces component set. Stay tuned for an upcoming blog entry with details on how you can take advantage of this in your own applications. Or, if you’re feeling adventurous, have a look at the showcase code to see how we did it!

Showcase - On OpenShift
We've deployed the showcase application to OpenShift -- the PaaS offering by Red Hat. The OpenShift Java EE 6 support provides a great platform to take your application all the way from development with Express (free!) to production with Flex (highly scalable!). Express is a shared multi-tenant environment made to be as simple as possible to get started quickly, while Flex gives you dedicated VMs and DevOps control over architecture along with monitoring. For the RichFaces project, this gives us the chance to showcase our components in a Java EE environment, where our framework really shines!

(Note, until 4.1 is released, the showcase at http://richfaces.org/showcase will continue to demonstrate the RichFaces 4.0 framework and components).

Showcase - New Component Samples
Additionally we’ve added some polish to the showcase with bug fixes and user experience tweaks, and we've included samples of the latest RichFaces components. You will now find showcase samples for the rich editor, notify, orderingList, and pickList components, complete with samples showing you how to put them to good effect in your applications.

Resource handling
Along-side these showcase improvements, we’ve introduced framework improvements to improve the mobile experience. With the new RichFaces 4.1 Resource Handling features, we are packaging and minifying the out of box JavaScript and CSS. This is in an effort to reduce HTTP requests made by the framework and to give mobile apps (or any app) a boost in performance. For those familiar with RichFaces 3, this also brings back the old LOAD_ALL configuration, albeit with a new name. We’ll have a blog post out shortly, with details on how you can try these features out with the Milestone 3 release.

Ajax Push
Last (and by no means least!) I’d like to mention that the AJAX push component has seen a lot of improvements with this release. We’ve introduced a CDI interface for firing push events. This is not intended to supercede the existing Push API, but is instead provided as a means to tie the powerful CDI event mechanism into the RichFaces push technology.

Coupled with earlier push improvements (removing the JMS requirement from the push component), the push component is shaping up to be much more accessible to developers working in either Java EE or Servlet container environments.

Forward: M4 & Stabilization
Work is already well underway with our M4 release, where we are improving on the compatibility of our components with mobile browsers, and adding a last round of small feature improvements. Give M3 a spin, and let us know what you think! Drop us a note in the forums, or join us for our weekly community/team meetings in IRC.

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!