Years ago I read a book called "Designing With Web Standards" by Jeffery Zeldman. One of the things it got me excited about was a semantic web, where the HTML in web pages describe the data or content, not the layout. The layout is completely removed from HTML, and done entirely with CSS. CSS Zen Garden is a great example of how a single HTML file can be rendered hundreds of completely different ways using CSS.

I think this is every web programmer's vision of perfection, but unfortunately it doesn't happen a lot. Tight schedules, lack of time to fiddle with CSS, differences between how browsers handle CSS, etc.

Back in October 2006, I remember eagerly awaiting the final release of the NetBeans 5.5 IDE as I do today for 6.0. Only days before the final release there was an announcement about a new pack for NetBeans – Visual Web Pack. Sun Java Studio Creator was being turned into an addon pack which would enable developers to create JSF web applications visually while taking advantage of the features of NetBeans 5.5. I downloaded the technical preview and have been using it ever since.

Sun has been working very hard on the NetBeans IDE and have been doing a phenomenal job, especially in 6.0. I thought that they might appreciate some constructive feedback from someone who uses Visual Web Pack frequently. I sent a rather long email to Winston Prakash from Sun, who is one of the architects of Visual Web Pack. He was pleased to read my feedback and had a lot of interesting things to say in response.

Today I was reading through the list of seminars to choose from at JavaOne. I received an email letting me know that all attendees must use the online schedule builder to build a schedule for the 4 day conference. I couldn't believe it, there were 373 seminars to choose from, and they go from 9:30 AM - 10:00 PM every day (some up until 11:45 PM)! It took me hours to go through them all and choose which to attend. Sometimes it was difficult to choose because I wanted two or more, but they were starting at the same time. I now have my schedule built and can't wait to attend. This is not just a tradeshow, this is an education! They teach you all kinds of industry best practices, the latest tools and libraries, and everything on your things to learn list. I didn't pay too much attention to which seminars are hands on, but I do know that the advanced web services security and dtrace training that I'm signed up for are both hands on.

While choosing, I noticed a couple back-to-back seminars on JBoss Seam, JBoss' web framework built on top of JSF. I have been using Sun's Visual Web Pack for a while (an alternative framework built on top of JSF) and had several major issues for the types of project I need to do. Sun employees told me that VWP was not made for those types of apps. For the most part I enjoyed working with it, but the issues I have are too big of a problem.

I have read that Seam is very good and noticed that it looks like a polished product based on their website. It was too late to swith my project over because it was completed by then. Another framework built on JSF that I have talked enthusiastically about before is Apache Shale. The features list describes exactly what I want, but it is too poorly documented and not officially relesed (alpha?).

I signed up for the JBoss Seam seminars so that I can learn more about it. Until JSF 2.0 is designed and standardized, Seam might be the right solution for me. I've read that it can use facelets (big +++++ for me), there's a NetBeans module to work with it, it will run on Sun Application Server 9, and there are some groundbreaking features that they have created that are becoming JSR standards. These features will be incorporated into the new JSF 2.0 standard. I think if I use Seam, the transition to JSF 2.0 won't be too bad since JSF 2.0 will have many of the same features.

Sun has gone public with a pre-JCP-filing of the JSR for JavaServer Faces 2.0. I've given it a quick skim and am very very excited about it. I've been working with JSF for a few months now and have uncovered several major issues for the projects I work on. Since then I realized why there are several frameworks built on top of JSF such as Shale, Seam and Visual Web Pack. Sun has gone through all of frameworks built on JSF including bolt-on modules such as facelets and AJAX libraries, and is going to build it all into the JSF standard. This means that any Java EE application server you use will have this incredible web framework built in, ready for you to develop with.

Here are some of the major highlights (from my point of view):

• Real world, production view description technology, including templating: include something influenced by Facelets, JSFTemplating or Tiles in the specification.
• Allow for bookmarkable JSF pages. More broadly, if HTTP GET can be used, it should be used.
• Provide a mechanism to minimize the "Lost Update" and "Duplicate Button Press" problems.
• Strategic additions to the Standard HTML RenderKit: Calendar, Tree, Tab View, Captcha, Login Panel, File Upload components.
• Enable components that publish events via RSS/Atom.
• Allow for "zero configuration" web applications. No faces-config.xml, no web.xml. If necessary, annotations will be used to supplement the configuration data.
• Expand the request processing lifecycle to be aware of Ajax. This may include describing a small developer-contract footprint JavaScript library as part of the JavaServer Faces specification. (They also mention a number of other features that make AJAX seamless)

We need this now!! It's kind of funny because it seems like JSF 2.0 fixes problems that other web frameworks have never had, and adds features that other web frameworks already have. I'm sticking with JSF because it is the JSR standard and for the most part I do like it. JSF 2.0 solves all the issues I have with it.

It looks like they don't plan on releasing the final draft until mid-end of 2008 when Java EE 6 is released :/ That feels like an eternity to me. Knowing Sun, they will be working on a reference implementation well before the final draft is released. I'm sure NetBeans' Visual Web Pack will make full use if JSF 2.0 at some point too.

I had a couple of specific comments about the JSF 2.0 spec that were not mentioned. I found a place to comment on the requirements: the JSF 2.0 Requirements Scratchpad document. I've added the following points:

• Regarding HTTP GET support, external systems should be able to do an HTTP GET or POST request to a JSF form that executes the action. For example, an external system wanting to pass in data for two fields of a search form and execute the search action to go directly to the results screen.
• Make sure that developers targeting mobile devices aren't forced into downloading tons of JavaScript and CSS for every page the way Visual Web Pack theme files do. Mobile web apps need very small HTML output, and there is very limited CSS and JavaScript support.
• Examine Oracle JDeveloper's JSF support for mobile devices. It appears that for each page being developed you can create a view for desktop computers and a view for mobile devices. They might even provide browser detection for displaying the correct view. Being able to develop a single JSF 2.0 web app that can target both desktop and mobile devices would be invaluable.

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.