Make A Custom RichFaces Skin

Using RichFaces in your application makes it easy to build great rich interfaces without spending a ton of time writing custom JavaScript for the front end and the back-end support for the JavaScript calls. It ties into your JSF components easily and makes dynamic interaction easy to build. It also comes with a number of default skins which is great when you’re first starting to build out a new application because it gives it a nice polished look instead of just black and white unstyled elements.

However, once you you get your own site design in place, the RichFaces skins probably won’t match your design perfectly. You can always override any of the particular element styles using CSS, but if you want to quickly change the global look and feel for all the RichFaces components, the easiest thing to do is to create a customized RichFaces skin.

You should start with the RichFaces skin that most closely matches your design and build your custom skin based on that. The skins are defined in properties files in the RichFaces jar file under /META-INF/skins/. You can also just download them from here, to avoid having to unpack the jar file yourself: richfaces-skins.zip.

Copy the skin file that’s closest to your design into your project. If you’re using a Seam project created with seam-gen, you’re in luck because the ant build file is already setup to deploy RichFaces skins if you have them. Just drop the skinname.skin.properties file into the “resources” directory of your Seam project. Rename it to a custom name for your site’s skin, i.e. mysite.skin.properties.

Now you need to configure your application to use the new custom skin. Edit /resources/WEB-INF/web.xml, and change the org.richfaces.SKIN param to the name of your new skin:

   <context-param>
      <param-name>org.richfaces.SKIN</param-name>
      <param-value>mysite</param-value>
   </context-param>

Now you can edit the skin file to adjust the colors and look and feel of the skin to match your site’s design. The ant build file will automatically deploy the custom skin file into the war file.

There are also other ways to customize RichFaces and build custom skins including extending an existing skin, or using the new Plug-n-Skin feature, or using XCSS, etc… But this should get you started!

RichFaces Refcardz from DZone

DZone has added a new, free, quick reference sheet (Refcardz) for RichFaces.

It’s a six page PDF that covers everything from how to install RichFaces, to the basic concepts of using RichFaces, all the way through information on each a4j and rich tag and example usage. Refcardz are free, and so far I’ve been very impressed with them. I also really like their Seam Refcard. It has come in handy several times.

Download the RichFaces Quick Reference Guide for free!

RichFaces Modal Panels, s:graphicImage, and IE6

If, like me, you are using the Seam s:graphicImage tag to serve an image from within a RichFaces modal panel, you may have run into an issue where in IE6 the image does not get displayed, and you get the dreaded red X of failure. It works fine in all other browsers, including IE7, and works outside of the modal panel, but not from within the modal panel.

It’s not a problem with the image data (saving the image from another browser and serving it up directly works fine. I suspect it’s a delay issue with the rendering of the modal panel. For me, it was serving up the red X about 90% of the time under IE6.

The “fix” is to stop using the s:graphicImage tag within the modal, and use a Servlet to stream out the image data instead. It’s pretty easy.

One gotcha I had was that I already had a Servlet handling video output, and I couldn’t find an example of how to configure two separate paths into the seam web:context-filter Servlet Filter (which allows access to Seam components, like the entity manager to load up the video/image items). A helpful response on the forums gave me this solution:


Also, if you’re struggling to figure out what a library’s new feature isn’t working for you, no matter how many permutations of the documented usage you try, check the versions in the manifest files in the library’s jars. Maybe, like me, you upgraded the jars in one project, but forgot to upgrade them in this one….

10MinuteMail Updates

I just pushed a new version of 10MinuteMail. Here are the notable updates:

  1. Removed the Ad-Aware links and text. No one was clicking on them anyhow.
  2. Added some translation fixes.
  3. Implemented AJAX based (RichFaces) refreshing of the list of e-mails in your inbox.
  4. Added smtp client throttling (in Postfix) to limit the number of messages accepted from a single source within 60 seconds. This seems to have already fixed the negative impact of high volume spammers on the function of the site.
  5. Removed the “Get Another E-Mail” feature. While this was a user request, I discovered that it was being abused by spammers.
  6. Added a Forward feature to allow you to forward a received e-mail to your home account for storage.

Enjoy! If you have any issues with the AJAX refreshes, let me know, but I think it should work better now.

Apache Proxy Breaks RichFaces

I’ve run into this twice now, so I wanted to document it here to help other folks, and to see if anyone knows the root cause of the issue.

When using RichFaces with Seam, things work just fine on my local development JBoss instance. But when I deploy the same EAR file up to my production JBoss instance, which is sitting behind an Apache proxy, everything works EXCEPT the rich/ajax stuff.

The issue was that the JavaScript located here: ContextRoot/a4j_3_1_4.GAorg.ajax4jsf.javascript.AjaxScript

would not load.

My Apache proxy was configured like this:

	ProxyPass /10MinuteMail balancer://mycluster/10MinuteMail/
	ProxyPass /10MinuteMail/* balancer://mycluster/10MinuteMail/
	ProxyPassReverse /10MinuteMail http://127.0.0.1:8080/10MinuteMail

With mycluster defined like this:

        
                AddDefaultCharset off
                Order deny,allow
                Allow from all

		BalancerMember http://127.0.0.1:8080
                #Allow from .example.com
        

Again, this configuration worked fine for everything EXCEPT that RichFaces JavaScript.

Since I am only using one node for 10MinuteMail, there is no real need for a load balancer configuration, so I replaced the configuration with this:

	ProxyPass /10MinuteMail http://127.0.0.1:8080/10MinuteMail
	ProxyPass /10MinuteMail/ http://127.0.0.1:8080/10MinuteMail/
        ProxyPassReverse /10MinuteMail/ http://127.0.0.1:8080/10MinuteMail/

Which works, and fixed the RichFaces reference.

So there’s your solution. However I have no idea what the actual root cause is.