JSF is a component-oriented, event driven web application framework. For those, that haven’t checked out JSF yet, I think it’s time! JSF 1.2 is now part of Java EE 5. I wouldn’t go into comparing JSF with Struts and other frameworks here… lot of folks did that already! I would just say that once you start working with JSF, you will realize what you have been missing all these years!

JSF like several other noted web frameworks follows the MVC pattern. The managed beans ala backing beans form the model, components form the view, and the Faces Servlet forms the controller. It’s the Component that’s the subject of this post. Components are typically UI components that are factory built, and come with rich features similar to AWT/Swing components. So, one key benefit JSF offers in terms of UI design is you have rich set of UI components to build desktop-like rich user interface applications, and also reduces the presentation layer development efforts dramatically.

JSF provides two ways of binding these components to data: Component binding and Value binding. Component binding binds the view component to a Java instance of the UI component in the backing bean. Value binding binds the value of the view component to a property on the backing bean.
Example of value binding:
The view component is defined something like this

<h:inputText id value=”#{myBean.someProperty}”/>

The backing bean property is defined as something like this

public class MyBean {

String someProperty = “”;

public String getSomeProperty() {

return someProperty;
}
public void setSomeProperty(String property) {
someProperty = property;
}

}

Example of component binding:
The view component is defined something like this

<h:inputText value=”#{ myBean.someProperty}”

binding=”#{ myBean.somePropertyInputText}”/>

The backing bean definition goes something like this

public class MyBean {

HtmlInputText somePropertyInputText;

public HtmlInputText get somePropertyInputText () {
return somePropertyInputText;
}
public void set somePropertyInputText (HtmlInputText input) {
somePropertyInputText = input;
}

}

There is always a debate whether you implement value binding or component binding in JSF. Personally, if you look at the component binding example, it starts looking like more .NETish… I guess it’s a matter of philosophy; I have seen developers writing backing beans with ton of code using component APIs embedded in it.

Though, sometimes it’s easier to work with the inherent component binding at the API level (ex: populating a list box using <f:selectItem>), personally I prefer to go with value binding and minimize component binding. Here are my reasons:
1. Gives a clean separation of UI design and Java code. Also from work division perspective, this is very relevant in environments where you have dedicated UI designers that focus on the component representation in the view part (xhtml, or jsp) and Java programmers for the Java side of the equation.
2. Besides separation of development efforts, value binding also gives opportunities for interchanging UI components that front a backing bean property very easily. You may decide that you would like a Scrollable Data Table instead of a Data Table, and accomplish it with no changes on the backing bean side.
3. JSF is very extendable where you can plug in UI component libraries from third parties. Rich Faces, Facelets, Ajax4jsf, JSF Avatar, etc. are some of the component libraries you can stack up on top of JSF. Component binding in such scenario will work against pluggable functionality if you decide to swap Rich Faces with let’s say MyFaces Tomahawk. Now, you will have to plow through your backing bean code to replace the component APIs with the new ones.
4. JSF also supports custom components. The above arguments about pluggability and isolation of UI APIs vs. managed bean code also hold good here.
5. When solving a business problem you think in terms of objects, their properties, relationships and interaction; not in terms of how those objects are mapped to a specific UI component. From a philosophical perspective, that’s my biggest reason for not using component binding and the component APIs in the managed beans.

Component binding does have it’s niche in situations where you want to implement valueChangeListener, or want to dynamically change the contents of a component (of course, you can Ajax enable your view and achieve the same without component binding in most cases). But, I would like to stick with value binding for 95% of my needs.