JSF Components: Why Most Don't Bother

March 05, 2007

I have been wanting to give JSF component development a whirl for nearly a year now, and I am happy to say that I finally got around to it! I decided to create a US phone number multi-input field with an autotab feature. I could not find anything out there like it, so I figured it was a good place to start. My procrastination on this task brings me to the first point I would like to make about the experience. It's painful. Ah, but relax. This entry is not about bashing JSF component development. I am a firm believer in the component approach, having reaped the benefits of using projects including Ajax4Jsf, IceFaces, and Seam on recent projects. Instead, my hope is to communicate some of the problems that I encountered so that together we can turn this ship around.

Many reviews of JSF component development are quick to criticize the number of steps required. I won't. I believe that you get out what you put in. If you want a slap-it-together type of product, then you use a slap-it-together type of approach. Components are supposed to be written once and used many, many times, just like a public API. Both should be designed carefully since they will become a vital foundation of a wide variety of applications. That makes them fairly hard to change once consumed. Besides, with Facelets forcefully squeezing JSP out of picture, you get to cut out all those crappy tab library steps. So the steps are really not the problem. Additionally, there are a couple of great resources that provide recipies for JSF component development. Among those resources are Pro JSF and AJAX and the JSF Component WritingChecklist.

The biggest pain in JSF component development is the lack of a standard Component Development Kit (CDK). If you have ever browsed any JSF component source code, this picture will come into focus very quickly. In fact, the source code may downright scare you. Since the HTML renderers for the standard components are not part of the specification, such as HtmlInputText, you have to include a dependency on one of the JSF implementations, such as MyFaces, just to get some of the common logic. While annoying and tedious, that is not even the worst part. JSF lacks base classes and libraries for all the following tasks.

  • Creating a FacesMessage from either the application bundle or a default bundle
  • Serving resource files, such as Javascript and CSS files, either once or multiple times
  • Rendering the universal HTML attributes (id, class, style, tabindex, event handlers, etc.)
  • String constants for the various HTML tags and attributes
  • Pretty printing the HTML output

This list is only a subset of what is missing. I just jotted these notes down will creating my US phone number component. This list only considers the Java classes that are absent. I really could have benefited from builders, compilers, code generators, and other such plugins. In short, JSF component development takes too long because of all the redundant tasks that must be done because of the absense of a decent CDK.

With the annoucement today of the partnership between JBoss and Exadel, the outlook for the future looks good. Not only is the RichFaces JSF component suite going to be released into open source, but the Ajax4Jsf CDK is going to receive a lot of attention and hopefully advocate the need for a standard. I am especially looking forward to the adoption of Ajax4Jsf's resource management framework, which allows JSF components to manage Javascript and CSS files elegantly. Currently, the situation for serving resource files is completely out of control, with each project tacking on yet another servlet or phase listener to intercept these custom requests. I see it as the primarly hurdle for JSF component developers. Fortunately, the solution may already have arrived. In a blog entry following the announcement, Gavin states, "...our goal is to build a deeply integrated and insanely productive development environment..." I believe that the JSF component development can actually be very enjoyable and worthwhile, but if we keep having to reimplement the same logic over and over again, not many folks will ever try it.

Posted at 07:42 PM in Java | Permalink Icon Permalink

4 Comments from the Peanut Gallery

1 | Posted by Sumathi on February 08, 2008 at 11:24 AM EST

Did you have sucess in developing the phone number component, if so can you please share your ideas on that.

Thanks, Su

2 | Posted by Dan Allen on February 09, 2008 at 03:05 PM EST

Yes, I did, in fact. You can find it as part of the bassline framework, which is my personal framework that I use to augment the Spring/JSF/Seam stack.

You can check it out from SVN using anonymous access.

3 | Posted by Ryan Gustafson on June 09, 2008 at 04:11 PM EST

Dan, I'm new to JSF/Seam but I found the Phone component in your bassline framework as a great starting point. Seeing how you approached the problem, I was able to create a generalized Aggregate component mini-framework, from which I was able to trivially realize Phone, SSN, Date, and Zip Code (that's just so far) implementations which don't really on gobs of JavaScript to function. In the process, I had to really learn JSF lifecyle much better than I had to date.

Someday I need to scan the rest of bassline to see if there's any other useful gems in the rough.

I've also got Seam In Action via MEAP, and look forward to the hardcopy, it's turning out to be quite the tome!

Thanks for sharing.

4 | Posted by Tim on October 13, 2009 at 06:50 PM EST

Is your custom jsf component for phone number still publicly available? The link above does not seem to work anymore.

Thanks.