Cay Horstmann has posted "JSF and Power Windows," making an analogy between the two of technology that's awesome when it works, and really nasty when it doesn't.
JavaServer Faces is like power windows. When stuff works, it is great. But when it fails mysteriously, it becomes expensive to figure out what went wrong. That's what just happened to me with a seemingly innocuous radio button set.
Sounds like JSF, doesn't it?
... the radio button never made it. Only the text area contents did. Firebug showed them in the POST request, but the radio button choice didn't make it into my bean. The setChoice method was never called, as I found out when setting a breakpoint there. (NB. The NetBeans debugger does a great job with debugging JSF apps)
After much debugging , I noticed that the getChoices expression (which yields all the radio button choices) was evaluated after the POST. I didn't understand that. The choices are needed for rendering the radio buttons but not for decoding. That's why I didn't bother to recompute them.
Except, I was wrong. In JSF 2.0, the power windows kick in. Some helpful soul decided that one might as well check that the request value is one of the choices, to thwart any fiendish person who has manually crafted a POST request. If the submitted value isn't among the choices, validation fails and the model is not updated.
In all fairness, having the choices available before the request is evaluated does make a kind of sense, although it definitely causes some interesting problems.
What's really sad is that this has always been JSF's reputation and legacy, even though it's far better than it was with JSF2 and has always been better than people (including me) thought it was. It just needs to be approached as if it's not just plain straight-up Java (because it's more than that, just like every other framework out there) - and thought of as being an event-driven, phased UI framework, which is exactly what it is.
JSF and Power Windows