When I first heard
about JavaServer Faces, way back at the 2002 Java One conference, it was sold
as “Swing for the Web”. That caught my attention. I was sick of
“assembly programming for the Web” with HTML, JavaScript, HTTP,
cookies, servlets, and that special form of torture—JSP custom actions.
Ever since, I have pinned my hopes on JSF because it has one thing going for
it: a component model. When I need, say, a progress bar, I want to
leave it to someone more skilled than me to make such a thing out of images,
JavaScript, or whatever. I just want to hook it up to some property that has
a progress value and move on to the next task. After all, when I use a
JProgressBar
in Swing, I don't worry about the pixels and
animations either.
In that regard, the first release of JSF was a cruel disappointment. The
standard JSF components are very primitive. The most sophisticated one is the
data table, and it pales in comparison with a Swing JTable
. No
progress bars, trees, menus, popups, or any of the other building blocks that
you want for a snazzy application. I don't want “FORTRAN for the
Web”.
In the last couple of weeks, I had to hack together a simple system to support classroom discussions. The instructor puts up a question, students give anonymous answers, and then the class looks at the collective wisdom and has a (learning insight|good chuckle). Many instructors use “clickers” for this purpose—special hardware devices with voting buttons. But I wanted students to send text and images, not just multiple-choice answers. (Also, they all already have a laptop, but they'd have to buy the clicker.)
At first, I thought, oh no, don't
make me eat
the elephant again, and I longingly looked at Rails, Grails, or Lift for my salvation. But
then I googled for "Rails progress bar", and the results were depressing. I
noted that NetBeans 6 has a perfectly good progress bar in the Woodstock component set, so I
decided to go with JSF once again. This time, Swing for the Web seemed within
reach. Here is what worked and what didn't.
faces-config.xml
.faces-config.xml
altogether, but I ran into some GlassFish
problems. Once WebBeans is integrated
into NetBeans/GlassFish, I will definitely go that route.Overall, I felt that I still had to focus far too much on the care and feeding of the app server. GlassFish programmers—remember that the app server is not just a tool to run perfectly working applications, it is also a part of the development environment!!! We need good error messages and red-hot deployment to be productive.
Swing for the Web is getting closer. Woodstock, RichFaces, Trinidad, all show promise. But do we really want all of them? After all, there is just one Swing. And if we must have them all, they should all play nice in a web GUI builder. JSR 276 should get us there—that started in June 2005. How time flies!
Apart from the UI components, we need more architectural guidance for mediating between the UI and persistence layer. I think JPA with Seam/WebBeans is our best bet, and NetBeans should support it ASAP.
All these issues are solvable, and I am hopeful they will be solved. I did enjoy having the Java API for all those other things I needed to do (such as crypto, zip file management, image manipulation, and so on). In the end, I was able to hack together a somewhat nontrivial application using NetBeans, GlassFish, JSF, and JPA, in a couple of weeks, while at the same time contending with sick infant twins and a broken clothes dryer. Not bad...but it could have been one week without the Stack Trace From Hell and redeploy, redeploy, redeploy.