validator="#{UserNameBean.validate}"/>     

Figure 2: This very simple JSF page shows some extended JSF tags.

Notice that things are starting to get a little complex. To be fair, some of the new syntax is not that bad. The inputText tag is kind of nice, actually. The problem is that JSF tags don't work and play well with other tags. For example, Figure 3 has a very common JSF bug.

Figure 3: Because of a common JSF bug, the sentences are reversed when rendered.

You would expect this to say: "Some text. Some more text." Instead, because of the intricacies of how JSF works in conjunction with JSP, you get "Some more text. Some text." And though this particular issue is supposed to be addressed in an upcoming release of JSF, it's clear to me that the specification isn't exactly ready for prime time.

People in the field have commented about the complexity of the JSF language, and at least one JSF proponent has argued that JSF is meant more for generation by tools than by people. That's an interesting way to look at things, and I'll address that in more detail in the last point of this article.

On the positive side, JSF includes a number of great UI components, such as tabbed panels, grids, and graphs. The implementation is a little complex for mere mortals, but once again, the syntax seems to be geared toward tools, not humans. On the weak side, it seems that the implementation is a little sparse on the client side, with no place for client-side validation or controller extension (the former is crucial for performance and more importantly the perception of performance, while the latter is important when implementing security and persistent sessions).
Finally, the navigation for JSF pages is the same as that for Struts. The application control file has a bunch of navigation rules, just like the Struts configuration file. It's called, not surprisingly, faces-config.xml, and it contains even more information than the struts-config.xml file. I'm not going to go into the file contents in detail; it's enough to say that the presence of this file makes JSF fit into the JSP Model I.5 architecture class.

JSF Tooling in WDSc

This is where it gets interesting. I've spent the first half of this column dissecting JSF and pointing out its flaws, so you might wonder why I even care about the WDSc support for it. One reason is that JSF is going to get better. A lot of people stand firmly behind it, and Sun itself seems to be betting the browser UI farm on this particular technology. (Is it the right one? Stick with me, dear reader, as I introduce you to some very interesting new technologies in upcoming articles. For now, let me tease you with a couple of terms like Tapestry and XUL. Stay tuned.)

The other reason, though, is that WDSc has outstanding support for it. I'm just getting my feet wet with the technology, and yet I was able to, in the space of about 90 seconds, create a Web page that went out, accessed my iSeries database, brought down records, and placed them in a table. Some vendors will sell you that particular capability for a few grand; you get it in WDSc for free.

Next, I stumbled through the tutorials for a few hours to find out how they worked. Not everything was perfectly intuitive, but after a couple of false starts, I was able to get back on track. Of course, the first thing I tried failed, but that was because my key field was a time stamp; like many tools, even WDSc is not completely comfortable with time stamps. After realizing I was perhaps overreaching a little bit, I went back to a simpler example. You can see a couple of the steps I had to perform along the way in Figures 4 through 8.

Figure 4: This wizard allows me to define a data table. (Click images to enlarge.)


Figure 5: This wizard allows me to modify the field characteristics for a single record.

Figure 6: This wizard specifies page navigation.

Figure 7: This wizard defines the parameters to pass to the next page.

Figure 8: All of those wizards combine to create this page (and its associated maintenance page).

Without much work, I was able to quickly create a couple of pages that would generate a list of records from a file and then let me add, update, or delete records from that list (actually, I skipped the add page for the second attempt, simply to save a little time). After that initial false start with the time stamp field, it took me only about five minutes to create and configure the application, even on my little 512 MB laptop running Windows XP Home.

The application worked flawlessly, or it did once I journaled the file. I was unable to find any quick way to remove the commitment control requirement for data access, so I had to journal the file, but that's a different argument for a different day.
However, the issue that quickly surfaced was the fact that the program did almost nothing. There's certainly no validation, either on the client side or on the server side (the lack of client-side validation is actually a big issue with JSF). More problematic, though, is the fact that I'm not exactly sure where to add that code. Moreover, if I do make changes to the validation, what happens if I make a change to the UI? Do my enhancements stay in place, or do they need to be recoded? That's traditionally been one of the bugaboos of generated code, and I see no reason to think that the problem has been solved.

Generated Code

I find the code being generated by tools today very disturbing. The trend seems to be toward code that cannot be maintained by human beings. In general, the entire programming concept seems to be being wrapped in fluffy clouds of XML that can only be understood (and maintained) by tools. The first step along this line was the SOAP specification, the most bloated and overblown design I've seen in a long time. Other technologies seem to be following suit, and the JSF tag library is just one of the latest.

The generated code from a JSF-aware editor is not only cumbersome, but also non-intuitive. That's really what I find difficult to bear: the fact that in order to debug this stuff I'm going to have to dig through a bunch of different places just to get a sense of what's going on. For example, with even a simple JSF application, you're combining the XML instructions from the faces-config.xml with the new tags of the JSF tag library. You also have to understand the Java class PageCodeBase, which is generated by the IDE. None of this is necessarily insurmountable, but I've seen this sort of thing happen more than once in my career: Code builders get smarter and smarter, and programmers become less likely to think creatively, instead relying on the tools.

Typically, a tool like this can generate simple applications in almost no time, and that short time to delivery is enough to excite both developers and managers, especially managers. Fast code! For free! But eventually, classes of programming arise that don't exactly fit the tools. And by then, the programmer is entirely reliant on the code generation tools and doesn't actually know what the code does. Therefore, rather than being able to modify the code, the programmer has to either shoehorn the feature into the confines of the tool or drop the feature entirely.

So Is This the Right Direction?

That depends on what you're trying to do. If, as the title of this article suggests, you're looking for one more way to create DFU or query applications, then this is certainly a good tool for your arsenal. But even IBM realizes that most applications need some business logic, hence the EGL language that's also included (which I introduced you to in my previous Weaving WebSphere column).

EGL, however, is no substitute for RPG, and the complexity of the JSF tag language is something I can't overlook, especially when more elegant solutions are available. For now, I just don't see JSF as the next great evolutionary step in Web application development.

Joe Pluta is the founder and chief architect of Pluta Brothers Design, Inc. He has been working in the field since the late 1970s and has made a career of extending the IBM midrange, starting back in the days of the IBM System/3. Joe has used WebSphere extensively, especially as the base for PSC/400, the only product that can move your legacy systems to the Web using simple green-screen commands. Joe is also the author of WDSC: Step by Step, Eclipse: Step by Step, and E-Deployment: The Fastest Path to the Web. You can reach him at This email address is being protected from spambots. You need JavaScript enabled to view it..