Usability problems in JSF

JSF is not perfect, nor the greatest thing since sliced bread. There, I said it!

What bugs me most (and remember, I'm still a big fan) is that JSF was supposed to be really easy-to-use. In many ways, it is very easy. But the reality isn't always quite so sweet. There's shortfalls that make the learning curve longer than it should be, and they are fixable.

The most annoying problem is that errors simply result in big stack traces. There's nothing wrong with stack traces per se, but by themselves they're totally insufficient for error diagnosis. Real diagnosis requires at a minimum:

• Line and column numbers, as well as file name. And even better, the snippet of content from that document that matches up.


• If an EL expression fails, information on what part of the EL expression failed. (When a complicated expression like #{foo.bar.baz == my.other.expression} fails, it's very hard to figure out what went wrong.)

In general, all exceptions thrown anywhere in JSF or JSPs should be vetted to ensure that they:

• Contain a meaningful, useful error message
• Contain enough context to point out what bit of user content failed
• Never, ever drop the base error, if one is being wrapped

A second category of annoyances in JSF consist of "nothing happened" problems. For example, if a validation error stops you from going on to Invoke Application, but you've forgotten to add an tag or something similar to your page, all that you see is - nothing.

Finally, when you do figure out what you've done wrong, quite often you need to bounce the server to pick up the changes. Any changes to WEB-INF/faces-config.xml require this. That's a huge productivity hit.

So, that's my hit list for JSF usability problems. What are your biggest JSF usability concerns?

[PS: Yes, I edited the wording a bit. It was coming across as an angry rant that JSF isn't useable, which isn't where I'm coming from.]

ADF Faces and JSF 1.2

JSF 1.2 is right around the corner, and, of course, ADF Faces is going to be right there too, right? Well, not so fast...

ADF Faces took one fairly unusual approach in designing its components. Instead of extending the standard UIComponentBase class like almost everyone else does, we directly extended UIComponent with UIXComponentBase. I chose this path for good reasons - like the FacesBean state saving approach I blogged about a few posts down - but it does carry a penalty. When UIComponent changes, ADF Faces breaks. And UIComponent does change in JSF 1.2. In particular, the move from the JSF EL to the new Unified EL means new getValueExpression() and setValueExpression() methods.

C'est la vie.

So, here's the good news: I'm promising, right here and now, to get a version of ADF Faces out soon that will be based on JSF 1.2. There's one big question to resolve: should it be based on the code in JDev 10.1.3, or on the post-10.1.3 code we're donating to MyFaces? I'm leaning towards the latter, but let me know if you feel differently.

What belongs in the JSF standard?

As the Expert Group starts working on JSF 2.0, we're faced with a very fundamental question: how do we pick and choose what belongs in the standard? And what, by contrast, does not belong in the standard?

There are several reasons why something should go in the standard:

1. Feature ABC cannot be implemented outside of the standard.


2. Feature DEF is not directly needed by the standard, but promotes interoperability.


3. Standards receive better tool support, and tool support is essential for feature XYZ.

Some examples of each:

1. JSF Avatar requires support from UIComponent, and therefore has to go into the standard.


2. The DataModel API allows interoperability between different model providers and component providers. It would be helpful if JSF had a TreeModel for the same reason - instead of everyone inventing their own TreeModel, we can have one abstract interface that lets model experts provide the best implementations possible and component developers design the best tree UIs around.


3. Facelets would benefit from tool support (Creator, JDeveloper, etc.)

But if you don't meet these standards, why not still add the feature to JSF? Why not add a calendar component? How about a declarative framework that makes it easy to create renderers? Or support for XSLT post-processing of content? These all seem like handy features, but I feel strongly that none belong in the JSF standard yet. A J2EE standard has very difficult constraints placed on it. The long development cycle means we only get to add features occasionally. But we're also required to maintain backwards compatibility, so fixing mistakes is difficult-to-impossible. So, here's a list of some reasons why not to add something to the JSF spec:

1. Feature ABC can be implemented just as easily outside of the spec as inside of it. That is, the current public API is entirely sufficient to implement the feature.


2. Feature DEF is not yet well understood - there are multiple possible directions to head. The JCP process works best when it standardizes existing best practices.


3. Feature XYZ is of only limited use - not everyone needs it.

These are not at all mutually exclusive lists. For example, the Avatar API is not the last word in handling AJAX requests for JSF. A declarative framework for renderers can be implemented outside the spec, but it would benefit from more tool support. And so forth.

Perhaps the most difficult task of any framework developer is learning how to say "No". As in, "No, we don't want that feature." But that is absolutely our responsibility as architects of JSF.

It's down there somewhere, let me take another look...
-- The Big Lebowski