JavaServer Faces

Abstract

JavaServer Faces are another way to take advantage of the MVC model for development. They are an important resource for reusing the view within an MVC design. This article describes an overview to the JavaServer Faces technology as well as how it works, and how it compares with similar technologies.

With software becoming increasingly the driving force in business everyday, enterprise development continues to evolve creating more extensive ways to manage information. With requirements of reusability and maintainability, it is no wonder component based methodologies present themselves. J2EE has done a phenomenal job in creating architecture and API’s for component-based development; JavaServer Faces are no exception.

JavaServer Faces simplify the creation of reusable user interface components in Java web applications. In short, JavaServer Faces encapsulate the complex portions of the view in MVC design. Originally, a client would send an HTML request to a J2EE web application. The implemented container would manage the request and send it off to a servlet controller. The servlet would then use Java Beans as the model, process information, and redirect the information to an appropriate view (JSP and HTML).

Herein lies a particular difficulty. Servlets are reusable components. If a servlet is implemented doing a particular task well, this servlet can be ported to multiple web applications with very little difficulty. This is the nature of component based development saving money and most importantly, time. Views by definition are proprietary to a particular web application. A personal website’s JSPs aren’t implemented on multiple web applications, because they have personal website information on them. JavaServer Faces eradicate this problem while providing even more pre-built functionality to the view portion of the MVC architecture. With JavaServer Faces, portions of a view on personal and business websites can be reused in numerous differing web applications. Moreover, they don’t even require the use of an HTML browser to display, and can be implemented to be rendered many different ways including WML. With this information in mind, how does it work?

Just like standard J2EE web applications, JavaServer Faces are powered by XML. Unlike standard J2EE web applications, this is not the application descriptor. JavaServer Faces implement another XML document alongside the application descriptor called the JSF configuration file. This configuration file declares the JavaServer Faces specific components such as: managed beans, validators, converters, navigation rules, and so forth. Although the syntax is beyond the scope of this application, this configuration file makes organization of the project incredibly easy as well as solidifies the loose coupling.

Besides linking XML, JavaServer Faces consist of two primary components. These components are JSF API and the tag libraries wiring JSF components to user interfaces. The JSF API is comprised of a series of specifications relating to: interface components, managed beans, validation, conversion, events, navigation, and rendering. The tag libraries contain the specification for integration of created components within a JSP page.

JSF user interface components represent component information and behavior. This component might be a button for example. This button would have attributes relating to the text displayed on the button, and when the button is clicked, it would fire an event. Of course, there is a framework provided to create custom user interface components. Another great features is the display for a particular component is independent of the component and a renderer is used to generate the display independent of a particular component.

Managed beans are java beans typically implemented to handle input and actions. EL can be used to bind a user interface component to a particular bean action or information. If the button example is used, the actionListener attribute of a button is set to a managed bean using EL. When the button is clicked, the method in the managed bean is fired. This method invocation is similar to swing and covers a lot of the event driven portion of JavaServer Faces. The user information is processed by the server, but what about validation?

Since validation is a must in any web application, integrated and custom validation is already provided in the framework. Simple validation rules can be applied to user input controls for things pertaining to lengths and ranges. The Common Validation API is also applied to almost all of the controls within JavaServer Faces. Since the validator framework is pluggable, it is easy to implement validation with any custom control as well. Now Java must handle the view redirection after the data is verified.

Navigation is one of the most interesting and powerful pieces of this package. Normally, the problem of navigation is generally solved through HTML links and server side redirection. Although this is sufficient, it creates a tight coupling between servlets, controls, and the display views. The navigation system within JavaServer Faces is managed through the JavaServer Faces configuration file. For any individual request pages, there can be a number of possible responses. These can all be managed with arbitrary labels which redirect to specified pages. For example: If I am specifying an authentication page, there can be a number of responses like success or failure or invalid username. These responses can all be individually mapped to independent pages. This gives an incredible amount of loose coupling keeping the component away from the individual implementation pages.

The other primary component of JavaServer Faces is the tag libraries. J2EE provides two different libraries. The JavaServer Faces core tag library and the JavaServer Faces HTML tag library. The core tag library accommodates the implementation of user interface elements in a form. This is validation, conversion, and event listeners. The HTML tag libraries house components for HTML aware browsers. These include input and output tags, command tags, and selection tags.

Although the setup of JavaServer Faces is similar to other technologies, JavaServer Faces have fundamental differences with similar implementations. Microsoft’s ASP.NET has a component based control implementation where the display code fires events to a code-behind file. The difference between Microsoft’s ASP.NET implementation and the JavaServer Faces implementation is the coupling. Since a code-behind is usually treated as one entity with the display, the ASP.NET implementation is simpler to use, but more tightly coupled with the view. JavaServer Faces are obviously useful, but what does it take to implement them?

To implement JavaServer Faces, one must first start with a JavaServer Faces compliant container. Once this is installed and configured, the only other pre-requisite is the latest Java Development Kit. Since this article is a primer to the technology and not a tutorial on creating JavaServer Faces, the actual code is beyond the scope of this article.

Although this article only scratches the surface of this incredible technology, it is easy to see JavaServer Faces are a phenomenal way to reuse MVC view code. They are pre-packaged with powerful tools, and are another way for developers to save time and effort within their development shops. For more information on implementing this technology, consult the sun website as they have an immense archive of tutorials.

Bibliography

JavaServer Faces Technology. The J2EE 1.4 Tutorial. Retrieved June 10, 2007 from http://java.sun.com/j2ee/1.4/docs/tutorial/doc/JSFIntro.html

JavaServer Faces. Wikipedia.com. Retrieved June 10, 2007 from http://en.wikipedia.org/wiki/JavaServer_Faces

Manganellore, Rakesh (2007) Introduction to JavaServer Faces. JavaBeat. Retrieved June 10, 2007 from http://jsf.javabeat.net/articles/2007/05/java-server-faces-introduction/