How to stay away from the JSF API

A few weeks ago, Ed Burns posted a link to a blog on the JSF expert group mailing list, commenting “A nice one, but it doesn't mention JSF 2”. Ever the curmudgeon, I pointed out that it wasn't so nice that the blog's sample code used the JSF API in beans when it wasn't necessary—as does in fact a lot of sample code, even in the official Sun tutorials. Ed's response: “Cay, a blog comment by such an eminent citizen as yourself would certainly be noticed.” So, here is the curmudgeonly eminence's advice on how to stay away from the JSF API. To set the stage, recall the basic mechanism by which JSF links the visual presentation with the application logic. JSF pages are composed of component tags that contain expressions in the oh-so-blandly named Expression Language (EL). For example, The class of the userBean object must have getters and setters for the password property: @Named public class UserBean { public String getPassword() { ... } public void setPassword(String newValue) { ... } ... } Here, the property has the type String, and that is good. There is no coupling between the UserBean class and the JSF API. You can compile and run unit tests of UserBean without having JSF around. You can even (gasp) switch to another view technology. So, where do programmers go wrong? Mainly in these four areas: SelectItem Data tables UIComponent The @ManagedB...

Date: January, 03 2010
Url: http://www.java.net/blog/cayhorstmann/archive/2010/01/03/how-stay-away-jsf-api

Others News