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
- 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.