JavaServer Faces - Basics

JSF is a server side user interface component framework for Java technology based Web applications. Often people think that itís a client side technology which is a misconception. Just as an example, client side UI framework is Swing.

Please note that it is server side instead of client side framework. JSF architecture includes many things that are related to UI management and are handled at the server instead of at client side. Please also note that JSF is a UI component framework. JSF architecture includes UI components that handle UI.

The primary goal of JSF is to allow tool vendors to provide easy to use
tools using JSF underneath. This provides the developers the ease of building Web
applications using drag and drop model as they do in standalone Swing based applications. An example is Sun Java Studio Creator.

Why JSF?

Following are the positives of JSF that answers the question: Why we should use JSF?

- JSF provides the Model View Controller based Web application framework.
- It provides clean separation of roles and is easy to use.
- It provides UI component framework which is extensible.
- It also provides rendering architecture in which UI components can be associated with multiple renderers.
- JSF is designed with multiple client types in mind.
- A clean separation between behavior, logic and presentation.

Servlet/JSP/Struts vs JSF

Often people ask that why we should use JSF when we have Servlet and JSP? Another question is why we should use JSF when we have Sturts?

Struts sure is a powerful framework but it was designed with a different focus. The focus of Struts is to provide a controller framework while the focus of JSF is to provide UI component framework.

Struts does not provide the built-in UI component model and it does not support UI component event model, nor state management of UI components, and because Struts is more or less tied up with HTML, it does not support the independence between UI components and a particular renderer.

Lifecycle if JSF page

The client makes an HTTP request for the page, and the server responds with the page translated to HTML. Since there are extra features that JSF offers, the lifecycle provides some additional services to process a page.

A JavaServer Faces page is represented by a tree of UI components, called a view.

The lifecycle starts when a client makes a request for the page. During the lifecycle, the JSF implementation must build the view while considering state saved from the previous postback.

When the client performs a postback of the page, the JSF implementation must perform several tasks, such as validate the data input of components in the view and convert input data to types specified on the server side. The JavaServer Faces implementation performs all of these tasks as a series of steps in the lifecycle.

The JavaServer Faces component architecture is designed such that the functionality of the components is defined by the component classes, whereas the component rendering can be defined by a separate renderer.

Component writers can define the behavior of a component once, but create multiple renderers, each of which defines a different way to render the component to the same client or to different clients.

Page authors and application developers can change the appearance of a component on the page by selecting the tag that represents the appropriate component/renderer combination

A render kit defines how component classes map to component tags appropriate for a particular client. The JavaServer Faces implementation includes a standard
RenderKit class for rendering to an HTML client. For every UI component that a render kit supports, the render kit defines a set of Renderer objects.

Each JSP custom tag in the standard HTML RenderKit is composed of the component functionality, defined in the UIComponent class, and the rendering attributes, defined by the Renderer.

A request for JSF page is made when a link is clicked or a button is pressed. In this, the JSF implementation begins the restore view phase.

If it is the first time, an empty view is created. JSF implementation builds the view of the JavaServer Faces page, wires up event handlers and validators and finally saves the view in the FacesContext.

The view for the presented greeting.jsp page will have the UIView component at the root of the tree, helloForm as its child and the rest of the JavaServer Faces UI components (userNo, submit, errors1) as children of helloForm.

Navigation model

Application developer is responsible for creating and defining the navigation model. It is defined in application configuration file (Facesconfig.xml).

Creating JSF page is simple and easy. There are few things to remember which I will list down.

The page must include JSF tag library and HTML and core tags.

All the JSF tags must enclosed between a set of view tag.
Use JSF form and form component tags.
Use <h:input_text> and not <input type=text>
Use <h:command_button> and not <input type=submit>
A page may include validators and event listeners on any form components

Review the code presented above. We have a text field named username whose value is mapped to logonBean's attribute username. This mapping info has to be in
faces-confog.xml and there has to be a bean with the required getters and setters.

Next step is to define page navigation rules in the configuration file.

As an application developer, you are responsible of writing the classes that handles business logic and data. In other words, you are responsible for backend part of the application. Lets assume that you are developing a newsletter subscription form. In that case you may create a class called Subscriber to hold the subscriber information:

The class defines a String attribute and a String array with getter and setters. We use standard conventions for getter and setter methods. This makes it easy to use properties of this class as JSF UI component models.

When a subscription is registered or updated, the information must be saved somewhere,
likely in a database or in some XML file. You have to write a separate class for persisting the contents.

To keep the example simple, we will simply print the contents on the console using the following method:

The SubscriberHandler class has two methods: a setter method (setSubscriber(...)) for associating it with an instance of the Subscriber class and a method for handling the Save button ActionEvent (saveSubscriber(...)). The saveSubscriber( ) method simply calls the save( ) method on the Subscriber instance and returns success.

Hereís a snippet of the configuration file with the declarations for the
example application classes: