I've nearly completed a project who's web user interface was built using NetBeans' Visual Web Pack, formerly Sun Creator Studio 2. It provides all kinds of visual editors for XML files, knows about JSF behaviors, code completion for JSF stuff and a visual page designer. There's a lot of things I like about it. The project I'm working on has a couple of requirements that have made me start to consider dropping VWP for now. The first problem is that our client has certain look & feel things they need for branding so that the system looks like it's part of their main site. All of VWP's components including the button, text box, label, etc... have nearly impossible to edit CSS burried deep inside of theme files. A theme is a VWP concept. It's a zip file that contains JavaScript, CSS and images that are used by the webuijsf component set that comes with VWP. All the components are tightly bound to it. You can't remove the theme. There is an RFE in the NetBeans 6 issues list to create a theme file editor to make it easy to customize the look of individual components. This would be great, except for the next problem I have with VWP for this project...

It forces every page to include all the CSS and JavaScript (at least it appears that way) which amounts to over 173 KB; even if you have only a text box and button on the page. Normally this wouldn't be too big of a problem for me, especially since the browser caches these files once downloaded. However, all of my pages have to have a second version that renders nicely on web enabled mobile devices such as smart phones and PDAs. You can't make mobile users download 173 KB of files on top of your page data. Most people pay through the nose per KB, and the download speeds in my area are about 1 KB/sec.

So, I started looking into other flavors of JSF. The one that caught my eye the most was Facelets. It replaces only the ViewHandler part of JSF. My code and deployment descriptors stay almost exactly the same, and I only need to replace my JSPs with XHTML facelet templates. Sounds wonderful, but unfortunately it isn't all peaches and cream. To use facelets I had to create a normal NetBeans web project, and add the facelets framework to it the same way you would add Struts framework support. I copied some of my source files over and started working on the templates. It didn't take long for me to realize that many of the handy things in VWP were not part of JSF, but part of a framework VWP built on top of JSF to make it more powerful and easier to use. For example, VWP page beans have event methods like prerender(), init(), destroy(), etc.. and have access to utility methods like getBean(). Those don't exist in plain JSF. The VWP designers created abstract classes that all managed beans extend, and a custom phase listener to fire events. I'm sure there's a lot more they've added. This made me realize that JSF by itself is missing a few important things.

I spent some time reading Craig McClanahan's blog. He's the architect who designed Struts, co-created the JSF spec, is one of the architects behind Sun Creator Studio and Visual Web Pack, and who also designed Shale. After todays experiences with Facelets, reading this blog entry about the motivation to create Shale made a lot of sense to me. Here is an important quote from a section where he was talking about the design of the JSF 1.0 specification:

Therefore, we chose to provide a set of rich extensibility points in the JSF request processing lifecycle, plus made it possible to plug in replacements for several of the standard functional pieces of JSF. While it is possible for an application developer to do this sort of thing, the extensibility is primarily oriented towards the needs of developers of two kinds of functionality -- JSF component libraries, and application frameworks built on top JSF. The hope was that, because JSF was on track to become a standard API (and part of the Java EE 5 platform), third parties would leverage these capabilities to provide substantially more functionality than the standard itself required.

Today there are a number of web frameworks built on top of JSF. Sun Creator/Visual Web Pack, Apache Shale, JBoss SEAM, Oracle ADF, Facelets, JSFTemplating, and possibly more. I'm getting the impression that if you are going to use JSF for anything serious, you won't be using raw JSF, you will be using one of the frameworks built on top of it. Isn't that wonderful? I don't think so. The reason I chose JSF was because when I first entered the Java world and wanted to make a web app I had to choose from a billion web frameworks, and JSF was the JSR standard framework. The only other one I considered was Struts. I ended up learning and using both.

The JSF framework I am now most interested in investigating to solve my problem at work is Apache Shale. There are a number of reasons I'm interested in this one. It was created by the same guy who created Struts. He has been working on making Shale usable with VWP (or at least the older version, Creator Studio). He says that he learned what developers liked in Visual Web Pack and made some things in Shale work the same way. Also, I think the Struts community is behind Shale either as a sister framework or a the Struts replacement. I'm a bit confused because I have also read about a Shale framework based on Struts? Anyway... unlike Facelets which only enhances the ViewHandler of plain JSF, Shale seems to be a complete solution like Visual Web Pack. It has something called Clay for the view which is similar to facelets. You create XHTML documents instead of JSPs. I'm looking forward to reading about it, but since it's almost bed time now it will have to wait until tomorrow. I need to do some reading before bed, and feast on some unhealthy bedtime snacks.

I think this article comes to the same conclusion about bare JSF needing some help by frameworks built on top of it like Shale.