The Data Access Object (DAO) support in Spring is aimed at making it easy to work with data access technologies like JDBC, Hibernate, JPA or JDO in a consistent way. This allows one to switch between the persistence technologies fairly easily and it also allows one to code without worrying about catching exceptions that are specific to each technology.

JSF supports Ajax by using a built-in JavaScript resource library that is provided as part of the JavaServer Faces core libraries. This built-in Ajax resource can be used in JavaServer Faces web applications in one of the following ways:

• By using the f:ajax tag along with another standard component in a Facelets application. This method adds Ajax functionality to any UI component without additional coding and configuration.
• By using the JavaScript API method jsf.ajax.request() directly within the Facelets application. This method provides direct access to Ajax methods, and allows customized control of component behavior.

The f:ajax tag is a JSF core tag that provides Ajax functionality to any regular UI component when used in conjunction with that component. In the following example, Ajax behavior is added to an input component by including the f:ajax core tag:

<h:inputText value="#{bean.message}">

 <f:ajax />

</h:inputText>

The lifecycle of a JavaServer Faces application begins when the client makes an HTTP request for a page and ends when the server responds with the page, translated to HTML.

The lifecycle can be divided into two main phases, execute and render. The execute phase is further divided into sub phases to support the sophisticated component tree. The JavaServer Faces application lifecycle execute phase contains the following sub phases:

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

JavaServer Faces technology offers the concept of composite components with Facelets. A composite component is a special type of template that acts as a component.

Any component is essentially a piece of reusable code that behaves in a particular way. For example, an input component accepts user input. A component can also have validators, converters, and listeners attached to it to perform certain defined actions.

A composite component consists of a collection of markup tags and other existing components. This reusable, user-created component has a customized, defined functionality and can have validators, converters, and listeners attached to it like any other component.

JSF  provides a set of standard classes and associated tags that page authors and application developers can use to validate a component’s data. The Validator classes in JSF are:

• BeanValidator – Registers a bean validator for the component.
• DoubleRangeValidator -Checks whether the local value of a component is within a certain range
• LengthValidator – Checks whether the length of a component’s local value is within a certain range. The value must be a java.lang.String.
• LongRangeValidator -Checks whether the local value of a component is within a certain range.
• RegexValidator -Checks whether the local value of a component is a match against a regular expression from the java.util.regex package.
• RequiredValidator -Ensures that the local value is not empty on an javax.faces.component.EditableValueHolder component.

All these validator classes implement the javax.faces.validator.Validator interface. Custom validators can be created by implementing this interface.

The f:selectItem and f:selectItems tags represent components that can be nested inside a component that allows you to select one or multiple items. An f:selectItem tag contains the value, label, and description of a single item. An f:selectItems tag contains the values, labels, and descriptions of the entire list of items. You can use either a set of f:selectItem tags or a single f:selectItems tag within your component tag.

The following example shows the usage of <f:selectItems> tag.

<h:selectManyCheckbox id=”languagecheckbox”

                      layout=”pageDirection”

                      value=”#{student.language}”>

    <f:selectItems value=”#{student.languageItems}”/>

</h:selectManyCheckbox>

This code snippet allows to select multiple check boxes from a list of languages from the Student managed bean.

The f:selectItem tag represents a single item in a list of items. The following example shows the usage of <f:selectItem> tag.

<h:selectOneMenu id=”studentGrade”  value=”#{student.studentGrade}”>

    <f:selectItem itemValue=”A”  itemLabel=”#{grade.A}”/>

    <f:selectItem itemValue=”A+” itemLabel=”#{grade.A+}”/>

    <f:selectItem itemValue=”B”  itemLabel=”#{grade.B}”/>

</h:selectOneMenu>

The itemValue attribute represents the value for the f:selectItem tag. The itemLabel attribute represents the String that appears in the drop-down menu component on the page, represents the value from the managed bean Grade.

Managed beans are lazily instantiated. That is, they are instantiated when a request is made from the application. For example, an application managed scope bean can be created using

@ManagedBean

@ApplicationScoped

public class DemoBean {

...

}

This bean is instantiated only when a request is made from the application.

To force an application-scoped bean to be instantiated and placed in the application scope as soon as the application is started and before any request is made, the eager attribute of the managed bean should be set to true as shown in the following example:

@ManagedBean(eager=true)

@ApplicationScoped

public class DemoBean {

...

}

The different scopes available in JSF for a managed bean are:

• Application (@ApplicationScoped): Application scope persists across all users’ interactions with a web application.
• Session (@SessionScoped): Session scope persists across multiple HTTP requests in a web application.
• View (@ViewScoped): View scope persists during a user’s interaction with a single page (view) of a web application.
• Request (@RequestScoped): Request scope persists during a single HTTP request in a web application.
• None (@NoneScoped): Indicates a scope is not defined for the application.
• Custom (@CustomScoped): A user-defined, nonstandard scope. Its value must be configured as a  java.util.Map. Custom scopes are used rarely.

A managed bean is a lightweight container-managed object (POJO) that works as a model for UI component. A managed bean is created with a constructor with no arguments, a set of properties, and a set of methods that perform functions for a component. Managed beans typically perform the following function:

• Validating a component’s data
• Handling an event fired by a component
• Performing processing to determine the next page to which the application must navigate

Managed beans are created using @ManagedBean annotation or using managed-bean tag in faces-config.xml. For example, a Student managed bean can be written as follows:

The EL defines two kinds of expressions: value expressions and method expressions.

• Value expressions can either yield a value or set a value of bean’s properties. Value expressions can be further categorized into rvalue and lvalue expressions. Rvalue expressions can read data but cannot write it. Lvalue expressions can both read and write data. The expression ${} are always rvalue and #{} can support both rvalue and lvalue expressions.

• Method expressions reference methods that can be invoked and can return a value. A method expression is a deferred method expression that is used to invoke an arbitrary public method of a bean, which can return a result.

For example, there is a managed bean called Student which has properties like name, id, age and a method called studentCount. The expressions #{student.name}, #{student.id}, #{student.age} represents deferred value expressions and #{student.studentCount} represents deferred method expression.