JSF 2 : A brief recall

JSF2

JSF 2 : what is it ?

JSF stands for JavaServer Faces and is an API (basically, it’s some Java interfaces). To use JSF, you need an implementation (which means you need Java classes that implement those interfaces). There are many implementations: the reference implementation from Sun and popular others like Icefaces, PrimeFaces (last one) and RichFaces.

In this section,  we will user the Richfaces implementation from JBoss. JSF is a Java framework for building browser-based user interfaces (UIs) out of reusable components. The emphasis here is on UI components. You won’t be dealing with the markup (HTML)  directly as you are probably used to doing, because JSF components will provide all the necessary user interface widgets to build the application. Within the components themselves, renderers (Java classes for generating HTML) are responsible for producing the appropriate markup. Because you are building web applications and the client is basically the browser, the markup needed is HTML (although it can be anything like WML, SGL, or even XML), so the components’ renderers will generate the HTML markup that will be sent to the client (browser).

Finally, it’s important to point out that JSF is a standard technology for building web applications. It is part of the Java EE 5 stack.

JSF Architecture

JSF implements what is known as the Model 2 pattern, which is based on the MVC architecture.

If you look at how the Model 2 pattern is applied in a JSF application, you can see it consists of three elements—the view, the navigation model, and the application
logic, as shown in the MVC architecture :

MVC architecture with JSF (Model 2)

Model

With JSF, the concept of a managed bean has been introduced. The managed bean is the glue to the application logic—backing code or backing bean. Managed beans are defined in the faces-config.xml and give the application developer full access to all the mapped backing bean’s methods. This concept of IoC is successfully used in frameworks such as Spring framework, for example.

View

The JSF view layer describes the intended layout, behavior, and rendering of the application. One of the cornerstones of a JSF application is the UIComponent. UIComponents are the foundation of the JSF view layer and represent the behavior and structure of the application. A developer would use these UIComponents to construct an application by nesting components within each other.

Controller

JSF comes with a simple controller—the FacesServlet. The FacesServlet acts as a gatekeeper, controlling navigation flow and dispatching requests to the appropriate JSF page.

What is the main feature of JSF ?

JSF offers a long list of features.

However, so as to not bore you by describing them all here We will just cover the two most important features: user interface components and events.

User Interface Components

UI components are the main feature of the JSF framework. JSF ships with 26 ready-to-use user interface components. Usually referred to as standard components, they provide basic user interface widgets for input, output, commands (buttons and links), labels, and layout, as well as simple controls to display tabular data.

For example, the following tag represents an input component:

<h:inputText value="#{order.amount}"/>

This is an input component that is bound (connected) to some Java object. You would place this tag on a JSF page instead of directly writing HTML code.The component behind the tag knows how to generate all the necessary and correct HTML, CSS, and JavaScript.

Component Rendering

The JSF framework allows the separation of a component from how it is presented (encoding) and how input is processed (decoding). The appearance of the component can be easily varied for the type of display device available (for example, a mobile phone). JSF provides out of the box, HTML 4.0 rendering kit.

Events

JSF takes you beyond the request/response paradigm and provides a powerful event-based model. The UI components that you use to build the user interface are sending events (when activated or clicked) to the server. Listeners then process the events.

For instance, in the #{simpleBean.save} expression defined in an action attribute, save is a method inside simpleBean bean. It is usually referred to as a JSF action and will be invoked when the button is clicked:

<h:commandButton value="Submit" action="#{simpleBean.save}"/>

Before we enter in a practical way in JSF 2, you must understand the six phases  show in the figure bellow which illustrate the life cycle of a JSF request and can give you lot of benefices in debugging :

lifecycle-conv-val-overview

The phases are :

  • Restore View
  • Apply Request Values
  • Process Validations
  • Update Model Values
  • Invoke Application
  • Render Response

For more details on these fundamental phases, I will recommend the nice article Request Processing Lifecycle phases in JSF available in the JavaBeat web site.

Ajax and JSF 2 specification

When JSF 1.x was developed, it didn’t have any Ajax features simply because Ajax didn’t exist as we know it to day.

Luckily in 2006 RichFaces came along and made it very easy to add Ajax functionality to existing or new JSF applications. For example, if you had a standard input text component like the following:

<<h:inputText value="#{order.amount}"/>

To send an Ajax request based on some event was very easy with RichFaces. All you had to do is add the <a4j:support> tag, specify the event to fire the Ajax request, and specify which components to rerender, as follows:

<h:inputText value="#{order.amount}">
<a4j:support event="onkeyup" reRender="id1"/>
</h:inputText/>
<h:outputText value="#{order.total}" id="id1"/>

When JSF EG (Expert Group) started working on JSF version 2, they introduced basic Ajax support into the specification. The Ajax behavior <f:ajax> in JSF 2 is closely based on the <a4j:support> tag.

Taking the above example, adding Ajax support in JSF 2 is done like this:

<h:inputText value="#{order.amount}">
<f:ajax event="keyup" render="id1"/>
</h:inputText/>
<h:outputText value="#{order.total}" id="id1"/>

This example looks very similar to the RichFaces 3 example.

The obvious changes are the new behavior (<f:ajax>), the event is specified without the on-part and instead of reRender, the render attribute is used. However, the core Ajax concepts are very similar. In addition to using <f:ajax> behavior, it’s also possible to send an Ajax request in a programmatic way, as follows:

<h:form id="form">
<h:commandButton id="button" value="Update"
onclick="jsf.ajax.request(this,event, {render:'form:out'}); 
return false;" />
<h:output Text value="#{timeBean.now}" id="out"/>
</h:form>

Even though basic, Ajax is now part of the JSF 2 standard.

An overview of RichFaces

If you are wondering why we need RichFaces if there is now Ajax functionality in JSF 2, it’s because the Ajax functionality in JSF 2 is very basic.

You only get <f:ajax> behavior. That’s not enough to build real rich enterprise Ajax applications. That’s exactly why you need RichFaces, a rich framework for JSF.

It consists of the following parts:

  • Rich and Ajax components divided into two tag libraries (a4j:, rich:)
  • Skins
  • Client-side and object validation extension for Bean Validation (JSR 303)
  • CDK (Component Development Kit)

RichFaces 4 is full compliant with JSF 2  and adds various rendering optimization attributes that we will cover in this section.

RichFaces’s Component Tag Libraries

RichFaces components are divided into two tag libraries: one tag library is called a4j:, and the other is called rich:.

The a4j: tag library provides page-level Ajax support and other utility tags. It basically provides foundation-like controls where you decide how to send a request, what to send to the server, and what to update.

The rich: tag library provides rich UI components. Rich components are anything beyond what the standard HTML tags provide; for example, a tab panel. There is no standard JSF nor HTML tag for a tab panel, so RichFaces provides one that makes it a rich component (beyond out-of-the-box HTML).

RichFaces Skins

RichFaces includes a number of predefined skins. These skins can be used in RichFaces web applications by specifying the skin name in the org.richfaces.skin context parameter in the web.xml settings file.

The predefined skins are as follows:

  • DEFAULT
  • plain, which contains no skin parameters and is intended for embedding RichFaces components into existing projects with their own styles.
  • emeraldTown
  • blueSky
  • wine
  • japanCherry
  • ruby
  • classic
  • deepMarine

Example (skin-chosser.xhtml)

<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:h="http://java.sun.com/jsf/html"
xmlns:f="http://java.sun.com/jsf/core"
xmlns:ui="http://java.sun.com/jsf/facelets"
xmlns:a4j="http://richfaces.org/a4j"
xmlns:rich="http://richfaces.org/rich">

<ui:composition>
<rich:panel>
<a4j:repeat var="skin" value="#{skinBean.skins}" iterationStatusVar="iterStatus">
<h:link value="#{skin}" includeViewParams="true">
<f:param name="skin" value="#{skin}"/>
<f:attribute name="style" value="#{(skin==skinBean.skin) ? 'color:orange' : ''}"/>
</h:link>
<h:outputText value = " | " rendered="#{not iterStatus.last}" />
</a4j:repeat>
</rich:panel>
</ui:composition>

</html>

Here the result of the treeview component and classic style using the skins features:

RichFacesMenus

RichFaces Client-side Validation

JSF comes with a number of out-of-the-box validators and JSF 2 now also supports Bean Validation (JSR 303). RichFaces 4 takes validation a step further and adds client-side validation based on Bean validation. With this feature, basic client-side validation no longer requires creating and plugging custom JavaScript validators to components; it just synchronizes them for different layers at the framework level. We will see that in action in a future post .

RichFaces’ Component Development Kit

Another part of the framework is the Component Development Kit (CDK). The CDK includes various Maven archetypes, a code generation facility, descriptors and tests generation facility, and a templating facility that allows the creation of renderer classes using only page code.

About these ads

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: