Welcome!

Java Authors: Elizabeth White, Liz McMillan, Esmeralda Swartz, Roger Strukhoff, Lori MacVittie

Related Topics: Java

Java: Article

Java Opinions: Geary vs Raible on JavaServer Faces (JSF)

Java Opinions: Geary vs Raible on JavaServer Faces (JSF)

"Whatever you do, don't use JSF. Not yet anyway." Those were the closing words of a devastating blog recently called "My JSF Experience" by J2EE consultant Matt Raible. "JSF is a technology that's likely to succeed," Raible added later - but his main beef with JavaServer Faces was clear: "Plain and simple, it does not simplify Web development."

This spurred the following spirited response from a member of the JSF Expert Group, David Geary. ("I do not speak for the group" when making these comments, Geary notes.)

David Geary writes: 

"Matt starts out by saying:

Of all the MVC Frameworks I've developed with in the last few weeks (Struts, Spring MVC, WebWork and Tapestry) - JSF was by far the worst. And it's not the implementations that are the problem, it's the spec itself (as far as I can tell). Plain and simple, it does not simplify Web development.

Ouch! I don't know what Matt thinks is problematic in the spec, because that's the last time he mentions it in his post. The list of complaints that follow in Matt's article refer to implementation-specific details of Sun's RI and MyFaces and some other things such as lack of JSF support, but nothing about the spec. So I'm not sure how to respond to that.

Also, I don't think that one of JSF's top priorities is to simplify Web development. Certainly that's a laudable goal, but you have to understand that JSF is: Web App Framework + Components + Event Model. That makes it considerably more complex than Struts, for instance, which is simply a framework. Also, JSF was designed primarily for use with tools, although I don't think that coding JSF apps by hand is necessarily more difficult than other frameworks of similar complexity (for instance, Tapestry). I'm sure Howard Lewis-Ship would take exception to that last assumption, but I think it's a pretty accurate statement.

Before I address Matt's specific complaints, let me say two things. First, JSF is not perfect and the Expert Group is well aware of its shortcomings, which we're working on for the next version. Remember, JSF is 1.0 (1.1 actually, but 1.1 is just a bug-fix release); I think Matt would've had a much different perception of JSF if he'd compared it against the 1.0 versions of Struts, Tapestry, etc.

Second, I'm not sure that spending a few days implementing a simple application in each framework is really enough to allow someone to recommend one framework over another. That said, I do think there is some value in such a comparison, but it's not the best vehicle for recommending one framework over another.

Now I'll address Matt's specific complaints:

MyFaces handles duplicate posts nicely. If you hit "reload" on your browser after saving a record, you get presented with an empty form rather than a duplicate record. I believe I got a duplicate record with Sun's RI.

The JSF RI is not very good at handling duplicate posts. It's something we're working on for 1.2.

The ability to specify an "action" attribute on a button (or a link) and them map that action to a page (in faces-config.xml) is pretty cool.

Yes it is!

Every button or link clicked results in a form post. That's just wrong - why can't I have true links like the web is supposed to? So much for bookmarks.

You can have true links: see the h:outputLink tag. For buttons, you can do <h:commandButton type="button"/>, which will give you a push button, not a submit button.

Saving state on the client results in enormously long URLs and/or hidden fields.

That's an implementation-specific detail of the RI (and perhaps MyFaces). The spec itself doesn't specify exactly how client-side state saving needs to be implemented. Also, remember that state saving is pluggable in JSF. If you don't like the way it works with your framework, you can plug in your own implementation.

JSF support is fairly non-existent. Unlike the other MVC frameworks, the MyFaces mailing list has hardly any traffic and the Sun forums aren't much better.

I can't speak for the MyFaces mailing list, but the JSF forum at Sun is quite active. See http://forum.java.sun.com/forum.jsp?forum=427.

I did find some CRUD examples, like this this one, but was disappointed to find that i18n is not considered for setting success messages. I ended up using the solution described in this post. 6 lines of code to set a success message - you've got to be kidding me! Most frameworks have a simple 1-2 liner.

This is the result of two competing forces when designing frameworks: the desire to provide the kitchen sink and the desire to provide a simple API. You can't have both, and this is one area where we deliberately chose to leave out functionality. In fact, you will find other cases (like accessing request parameters) that may seem to be more work than is necessary. I would suggest that you encapsulate those 6 lines in a utility class of your own, which reduces it to one line going forward. Of course, the cost of those 6 lines lies in figuring out how to do it in the first place. You can obviate that need by using good utility classes that someone else has already written. You can find such classes at http://www.corejsf.com.

Waiting for JSPs to compile the first time has surprisingly become painful after using Tapestry, Velocity and FreeMarker for the last 2 weeks.

JSF desperately needs to support an alternative display technology besides JSP out of the box. In fact, it's much uglier than simply having to wait for JSP pages to compile. See Hans Bergsten's article "Improving JSF by dumping JSP" at onjava.com.

Validation messages are ugly. For instance, when a required field isn't filled in, I get: "lastName": Value is required. I was able to override the default messages, but I was never able to use the label of the field (vs. the field's id).

The standard messages are indeed ugly, but it's a cinch to replace them. You should be able to use the field's label.

The <h:messages> tag is practically worthless. Sure it's great for displaying messages (error and success), but that's about it. It has a "layout" attribute that doesn't even work in Sun's RI, and in MyFaces it just wraps a <span> with a <ul><li> or a <table>. Both of these layouts are useless b/c you can't set a css class on them. I ended up using "table" and having to set a generic CSS rule (width: 100%) in order to get the message/error bar to show across the top of my page. This tag also doesn't allow you to escape HTML.

The h:messages tag could certainly be improved, but the layout attribute does work in Sun's RI and you can set a CSS class on them. See the end of chapter 4 in Core JSF. (I'm convinced that Matt needs a good JSF book!)

The h:dataTable component is nothing like the displaytag. MyFaces claims to have a pageable/sortable component, but it requires custom logic/methods in your managed-bean. Yuck. I ended up using <h:dataTable>, which has neither sorting or paging. This is only because I couldn't get an <h:commandLink> working inside a displaytag column.

h:dataTable could definitely use some attention.

JSF-created apps are pretty much untestable. Managed-beans are testable, but the UI seems really difficult with jWebUnit and Canoo's WebTest. IMO, it should be possible to specify a URL to edit a record (i.e. editUser.html?id=2). With JSF and my master/detail app, the link to edit actually sets about 5 hidden form fields with JavaScript and then submits the form. I could probably figure the URL out, but it'd be ugly. Also, the MyFaces h:dataTable will not render an "id" attribute if you specify one. This is needed to verify tables and their data with jWebUnit.

Testability is another area that could use some improvement. At least actions can be implemented in POJOs (unlike Struts), which means that you can test business logic with JUnit.

Finally, Matt mentions that he felt like he was banging his head against the wall with both Tapestry and JSF. I would assert that trying to come up to speed with any framework in a couple of days will result in considerable weeping and gnashing of teeth."

More Stories By David Geary

David Geary is the president of Sabreware, Inc., a Java training and consulting company. David has developed object-oriented software for nearly 20 years and worked on the Java APIs at Sun Microsystems from 1994 to 1997. He is the author of six Java books, including the Graphic Java series, Advanced JavaServer Pages, and Core JSTL. David is a member of the expert groups for the JavaServer Pages Standard Tag Library (JSTL) and JavaServer Faces; was one of the earliest contributors to the Apache Struts application framework; and wrote test questions for Sun's Web Component Developer Exam. David is the co-author of the soon to be released Core JavaServer Faces, which is published by Sun Microsystems Press.

Comments (13)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.