Swing for the Web--Are We Getting Closer?
style="margin-right: 1em; width: 20%; float: left;" />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
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,
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
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
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
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.)
style="margin-right: 1em; float: left;" />At first, I thought, oh no, don't
make me eat
the elephant again, and I longingly looked at href="http://www.rubyonrails.org/">Rails, href="http://grails.codehaus.org/">Grails, or href="http://liftweb.net/index.php/Main_Page">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 href="https://woodstock.dev.java.net">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.
- The Woodstock
components look pretty nice—much nicer than anything that I could
put together with my limited CSS skills. For example, the alert component
has some shading, some graphics, all that stuff that I am too busy to
work on. Exactly what you want from a component set.
- The progress bar
worked great. I didn't have to know anything about AJAX. That's good
because I really don't want to know any more about AJAX than about href="http://asn1.elibel.tm.fr/">ASN.1. For an application
programmer, this should just be plumbing.
for the Woodstock components is totally wretched.
- The NetBeans
form designer is adequate for dragging together a basic UI, but it
insists on the “Creator” model where each JSF page has a
backing bean with bindings for each component. That may make sense for
ASP.NET programmers, but I hated it. Apparently, this will go away in
Netbeans 6.1. I used the form designer for the initial layout, then
converted everything to plain JSF. I also had href="http://www.nabble.com/visual-web-JSF-page--jsp-and-design-out-of-sync-td14750202.html">other
issues that hopefully will get addressed in a future version of the
- Achieving a
common page layout, with a title bar on top and a menu on the left, is
still way too hard. I want the framework and tools to guide me, not fuss
with page fragments.
- I used the XML JSP
syntax and XHTML for the pages, and NetBeans caught all my silly
formatting errors—a big help. (Why don't I follow that good advice
in Core JSF? I tried, but my co-author and the reviewers all felt
nostalgically attached to ye olde syntaxe.)
- NetBeans is pretty
good about keeping the various configuration files in sync, and I didn't
have to fuss much with
- If I had used
Seam, I could have
faces-config.xmlaltogether, but I ran into some href="http://forums.java.net/jive/thread.jspa?messageID=253975𾀗">GlassFish
problems. Once href="http://jcp.org/en/jsr/detail?id=299">WebBeans is integrated
into NetBeans/GlassFish, I will definitely go that route.
- JPA was a winner.
Having the ORM and caching for free is nice, and JPQL is far less tedious
than SQL. I spent essentially no brain cycles on persistence. Mostly,
that was because my app is so simple that I never felt the need to export
any entities outside the managed environment. Again, Seam/WebBeans would
make this even nicer.
- I still got
Trace From Hell far more times than I wanted to. NetBeans did a
fairly creditable effort in trying to scrape what little useful file
name/line number data it could find. This still needs lots more work. For
example, errors in session beans are silently swallowed.
- The NetBeans
debugger saved my bacon many times. It is very savvy about tracing from a
JSF bean to a session bean, bypassing the intermediate layers.
- I tried my
best to use hot deployment, and even hot-switched code whenever possible.
But every time that I edited a JSF page or even a CSS file, I had to
redeploy, redeploy, redeploy, and each time, I stared at the console for
what seemed like an eternity. I hated that. My Rails friends tell me that
they can keep tinkering with their code without ever redeploying.
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,
href="http://myfaces.apache.org/trinidad/">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. href="http://jcp.org/en/jsr/detail?id=276">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,