Java Server Faces: a first look

In the beginning there was Java Servlets: Server-side Java code to handle HTML posts. That was a breakthrough. Then the world gets sick of cranking HTML outputs with out.println("<table><tr><td>Your result is..."); Then there was the ingenious idea of embedding Java code right inside HTML, and there was Java Server Pages JSP. Waita minute, does this ingenious idea come from copying Microsoft's ASP? JSP is out for a decade now.

Since then, people has always wanted to organize their JSP pages with their java classes. For years people try to use XML to associate their JSP and java files and handle the submit button actions. The Model-View-Controller is exactly what people want to do. Many such frameworks exist, most notable is Struts and Spring (terminology came from supporting elements of your car under the hood).

The idea of these frameworks is to first hack the WEB.xml in java project to handle files with .do or .whatever extension to be processed in their servlet hidden in their jars. That servlet will figure out how to direct to the corresponding java "controller" object to handle initializing or any submits by looking at some XML configuration files.

Frameworks may make use of custom tag library (a feature of JSP) to make you relearn all the HTML tags that you know and love to make it play well with the framework.

Sun came up with its own: Java Server Faces (JSF). It is worth noting because it comes from Sun.

The idea is this: every page is associated with a bean. Beans are nothing more than some private variables and get/set methods. The association is in the faces-config.xml file. Then each JSP has a list of navigation rules. Submit button hit? make it call your method, or go to another "view", which is the JSP.

Every HTML element is re-implemented by the html taglib. instead of <INPUT type=text...> you do <h:inputText...>
The upside: JSF provides validation rule, such as make that a required field. (Ok, I can implement my own flexible rules too, the way *I* want it)

JSF adds additional syntax with the # and the {} in accessing your bean, like <h:inputText value="#{myclass.firstName}">

You can define a HTML data table and use the taglib so that you don't have to write a loop to loop through your results.

Doing View Source on the generated page reveals each javascript is generated for you to do all sorts of stuff. We are one more level of abstraction: we don't handcode those javascript. One way to look at it is that it is better because of less code, another way is that it reduces your flexibility.

I am still learning what JSF can do, it looks like you can do a lot, including working with AJAX. The cost of is new taglib syntax and use one bean per page, and be careful with that faces-config.xml. Note: The JSF file itself gives no clue about where the bean it is using is located, no import statement is there. I like this simple tutorial: http://exadel.com/tutorial/jsf/jsftutorial-kickstart.html

It is worth noting because it is part of Java, and seems to be endorsed by a lot of web applications.