JSF-Java Server Faces

Q. What is Java Server Faces?
A. Java Server Faces (JSF or Faces) is a user interface(UI)framework for building Java web applications. JSF is a server-side component framework that allows to think in terms of components, events, backing beans, and their interactions, instead of requests, responses, and markup language.

Its goal is to make web development faster and easier by supporting user interface components(such as text boxes, list boxes, tabbed panes, and data grids).

JSF contains an API for representing components and managing their state; handling events, server-side validation, and data conversion; defining page navigation; supporting internationalization and accessibility; and providing extensibility for all these features and their tag libraries for adding components to web pages and for connecting components to server-side objects.

Q. Why Java Server Faces?
A. JSF is a component-based framework for developing the user interface of a web application. Suppose, to display a table with rows and columns,no need to generate HTML tags for rows and cells in a loop but add a table component to a page,reuse of own components and use of third party component sets is possible.

Here is why!
Because-

• JSF is a standard specification.
  –JSR 127.
  –Part of J2EE 1.5
• JSF exposes a component and event based
  programming model.
• JSF is tool friendly.
• JSF is implementation agnostic.

Q. Explain the versions of JavaServer Faces ?
A. The versions of JavaServer Faces are:-

• JSF 2.2 (2013-05-21) — introduced new concepts like stateless views, page flow and the ability to create portable resource contracts.
• JSF 2.1 (2010-11-22) — maintenance release 2 of JSF 2.0. Only a very small  amount of specification changes.
• JSF 2.0 (2009-07-01) — major release for ease of use, enhanced functionality, and performance.
• JSF 1.2 (2006-05-11) — many improvements to core systems and APIs.
• JSF 1.1 (2004-05-27) — bug-fix release. No specification changes.
• JSF 1.0 (2004-03-11) — initial specification released.

Q. What’s New in JSF 2.2 ?
A. JSF 2.2 (JSR 344) is an evolution from 2.1 and a step forward as it brings the following new features:

• HTML-friendly markup.
• HTML5 content with their id attribute fully compatible with the JSF.
• Faces Flow.
• Queue control for AJAX requests.
• Injection in all JSF artifacts.
• Moving to CDI.

Q. List the benefits of JSF?
A. The major benefits of Java Server Faces technology are:

1. Provides a clean separation between behavior and presentation for web applications.
2. With the use of built-in UI component library user interfaces can be created easily.
3. Allow to build web applications that implement the finer-grained separation of behavior and presentation that is traditionally offered by client-side UI architectures.
4. Allows to focus on a single piece of the development process and provides a simple programming model to link the pieces.
5. Aid familiar component and web-tier concepts without limiting to a particular scripting technology or markup language.

Q. Lists the main packages defined in Java Server Faces 2.2?
A. The main packages along with their description are as follows-

1.  javax.faces
   The core Java Server Faces APIs
2. javax.faces.application
   APIs used to link an application’s business logic objects to Java Server Faces.
3. javax.faces.component
   Fundamental APIs for user interface components.
4.  javax.faces.context
   Defines each request state information.
5. javax.faces.convert
   Classes and interfaces defining converters.
6.  javax.faces.event
   Interfaces describe  event listeners, and concrete event implementation classes.
7. javax.faces.flow
   Classes and runtime API for Faces Flow.
8.  javax.faces.lifecycle
   Classes and interfaces defining life-cycle management for the JSF implementation.
9.  javax.faces.render
   Defines the rendering model.
10. javax.faces.validator
    Interface defines the validator model and the concrete validator implementation classes.
11. javax.faces.webapp
    Classes required for integrating JSF into web applications, including the standard FacesServlet.

Q. What is the directory structure of a JSF application?
A.  A  JSF application is deployed as a WAR file with extension .war. The directory structure that follows a standardize layout-

[code lang=”plain”]

XHTML files

|–resources/
| -CSS files, JavaScript, images
|
|–WEB-INF/
|
| -servlet and JSF configuration files
|
|–classes/
| |
| |-class files
| |
| |–META INF/
| -application server configuration files
|–lib/
-library files
[/code]

Using the Tomcat or some other servlet runner, the lib directory contains the JAR files of JSF implementation but in the case of Glassfish and other Java JEE application server they already have JSF built in.

Q. Explain the architecture of JSF?
A. Mostly the web frameworks use the Model-View-Controller (MVC) design pattern, as does JSF. MVC is an architectural pattern used to isolate business logic from the user interface.When MVC is applied, it results in a loosely coupled application.In MVC, the model represents the data of the application and it can be consist of backing beans,EJB calls, JPA entities, and so forth.The view corresponds to the UI .In JSF the view is the actual XHTML page, when we deal with,web interfaces and controller manages the communication between both Architecture of JSF.
JSF applications are standard web applications that intercept HTTP requests via the FacesServlet and produce HTML.
Whenever a user manipulates a view, it informs to a controller of the desired changes.
The controller then gathers, converts, and validates the data, invokes business logic, and generates the content in XHTML. In JSF, the controller is the FacesServlet.

Several important parts of JSF that make its architecture rich and flexible:

• FacesServlet and faces-config.xml: In JSF, the controller is the FacesServlet.This is the main Servlet for the application and can optionally be configured by a faces-config.xml descriptor file. Now a days most metadata can be defined through annotations.
• Pages and components: The JSF allows multiple page declaration language(PDLs) but Facelets is the suggested one since JSF 2.0.
• Renderers: Renderers are organized into render kits and are responsible for displaying a component and translating a user’s input into the component property values.
• Converters: These convert or translate a component’s value (Integer, Date, Enum, Boolean, etc) to and from markup values (String).
• Validators: These are responsible for ensuring that the value entered by a user is valid and acceptable. With a single component one or more validators can be associated Some of the validators are LengthValidator, RegexValidator, etc.
• Backing beans and navigation: The business logic is made in backing beans, which also control the navigation between pages.
• Ajax support: JSF 2.2 comes with built-in support for Ajax. Ajax support added in the form of a JavaScript library (jsf.js) defined in the specification and a tag.
• Expression language: EL is used in JSF pages to bind variables and actions between a component and a backing bean.

Q. What is Java Server Faces Application  consists of?
A. A typical Java Server Faces application includes the following parts:-

• A set of web pages.
•  To add components to the web page by the set of tags.
• A set of  beans that are lightweight, container-managed objects. In a JSF application, managed beans serve as backing beans, which define properties and functions for UI components on a page.
• A web deployment descriptor (web.xml file).
• To add the component to the web page with the use of set of tags.Navigation rules,configure beans and other custom objects defined by the faces-config.xml file (use optionally).
•  A set of custom objects, which can include custom components, validators, converters, or listeners, created by the application developer (use optionally).
•  A set of custom tags for representing custom objects on the page (use optionally).

Q. Explain briefly the lifecycle of a Java Server Faces Application along with their phases?
A. All applications contain lifecycles and during a web application lifecycle  some common tasks are performed, such as handling incoming requests,decoding parameters,modifying and savingstate,rendering web pages to the browser.

In case of simple applications lifecycle phases manages automatically and in case of more complex applications lifecycle phases manages manually as required.

Beginning of the lifecycle of a Java Server Faces application occur 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 subphases and the JSF page is represented by a tree of components, called a view.

The Java Server Faces implementation must build the view.Mainly clicking a button causes a request to be sent from web browser to the server. This request is translated into an event that can be processed by the application logic on the server. All data input by the user enters a phase of validation before the model is updated and any business logic invoked.

JSF is then responsible for making sure that every graphical component is properly rendered to the browser.

The given figure shows the different phases of a JSF page life cycle.

The Java Server Faces application lifecycle Execute phase contains the following subphases:

1. Restore View Phase
2. Apply Request Values Phase
3. Process Validations Phase
4. Update Model Values Phase
5. Invoke Application Phase
6. Render Response Phase

1. Restore View Phase:
Whenever a request is made mainly by an action, such as the Java Server Faces implementation begins the Restore View phase.

In this phase, the JavaServer Faces implementation builds the view of the page, wires event handlers and validators to components in the view, and saves the view in the FacesContext instance.

2. Apply Request Values Phase:
After the component tree is created, each component in component tree uses decode method to extract its new value from the request parameters. The value is then stored locally on each component.
If the conversion fails, an error message associated with the component is generated and queued on FacesContext.
At the end the components are set to their new values, and messages and events have been queued.

3. Process validations Phase:
In this phase, the JSF processes all validators registered on component tree by its validate method.
For the validation, test the component attribute rules and compares these rules to the local value stored for the component.
If this value is invalid,error message to the FacesContext instance is added by the JSF, and now the life cycle display the same page again with the error message.

4. Update Model ValuesPhase:
The data is valid this is checked by the JSF, now it moves across the component tree and set the corresponding server-side object properties to the components local values.The bean properties corresponding to input component’s value attribute will be updated by the JSF.

5. Invoke Application Phase:
In this phase, the JSF handles any application-level events, such as submitting a form or linking to another page.At this point, if the application needs to redirect to a different web application resource or generate a response that does not contain any Java Server Faces components, it can call the FacesContext.responseComplete method.

6. Render Response Phase:
In this phase, JSF builds the view and delegates authority to the appropriate resource for rendering the pages. Subsequent requests can be access after the content of the view is rendered,so the state of the response is saved. Now the saved state is available to the Restore View phase..

Q. When the initial request occurs in JSF lifecycle?
A. An initial request occurs when a user makes a request for a page for the first time and the lifecycle executes only the Restore View and Render Response phases.

Q. When the postback request occurs in JSF lifecycle?
A. A postback request occurs when a user submits the form contained on a page that was previously loaded into the browser as a result of executing an initial request and the lifecycle excutes all of the phases.

Q. Name the phases that generate messages in the lifecycle of JSF ?
A. The four phases that can generate messages are apply request values, process validations, update model values, and invoke application.

Q. Distinguish between struts and JSF?
A. The differences are given below:-

•  JSF is a specification while Struts is an open source framework.
• JSF action methods can be implemented in Java objects but Struts actions are tied to Struts API.
• JSF has event model which reacts on value changes, actions and phase changes in JSF lifecycle while in Struts, there are no such event models.
• JSF uses Dependencies Injection but in Struts, there is no Dependencies Injection.
• JSF supports navigation by defining a navigation rule in the faces configuration file but Struts use the notation to define navigation.
• JSF component tag does not generate HTML instead they refer a component renderer pair on the server while Struts tag generates HTML directly.

Q. Explain the Anatomy of JSF Components?
A. A JSF page is a tree of components. Some of its components have an HTML representation, that allow to validate, convert data, or enable Ajax invocation.To design the Web pages use the several components.

• JSF built-in HTML, Core, and Templating components,
• JSTL tags,
• Own homemade components, and
• Third-party components (open source or commercial).

These components need external resources such as images, CSS, or JavaScript. JSF manages these resources.JSF pages access to implicit objects allowing components to use HTTP request parameters, cookie information, or HTTP headers.

Q. List the Standard JSF UI Components?
A. JSF UI Components along with their description-

UIColumn Represents a column in the parent UIData component.
UICommand Represents graphical components such as buttons, hyperlinks, or menus.
UIComponent Base class for all user interface components in JSF.
UIComponentBase Convenience class that implements the default concrete behavior of all methods defined by UIComponent.
UIData Supports data binding to a collection of objects; commonly used to render tables, lists, and trees.
UIForm Represents a user input form and is a container of other components.
UIGraphic Displays an image.
UIInput Represents components to input data such as input fields, text areas, and so on.
UIMessage, UIMessages Responsible for displaying one or several messages for a specific UIComponent.
UIOutcomeTarget Represents graphical buttons and hyperlinks that enable bookmarkability.
UIOutput Represents output components such as labels or any other textual data output.
UIPanel Represents UI components that server as containers for others without requiring form submission.
UIParameter Represents information that requires no rendering.
UISelectBoolean Represents check boxes and allow the selection of one or many items.
UIViewAction Represents a method invocation that occurs during the request processing life cycle.
UIViewParameter Represents a bidirectional binding between a request parameter and a backing bean property.
UIViewRoot Represents the component tree root and has no graphical rendering.
UISelectItem, UISelectItems Represent a single or multiple items in a selection list.
UISelectOne, UISelectMany Represent components like combo boxes, list boxes, or groups of check boxes and allow the selection of one or many items.
UIViewAction Represents a method invocation that occurs during the request processing life cycle.
UIViewParameter Represents a bidirectional binding between a request parameter and a backing bean property.
UIViewRoot Represents the component tree root and has no graphical rendering.

Q. Name the available implementations of JavaServer Faces?
A. The implementations of JavaServer Faces are-

Reference Implementation (RI).
Apache MyFaces implementation.
ADF Faces  implementation.

Q. Is JSF support more than one Faces Configuration file?
A. Yes, JSF supports  more than one configuration files for registering in web.xml  under <context-param> tags and follow naming convention like  faces-configXXXX.xml, you can use module name, numbers or alphabet or combination in place of XXXX, main concern here file name must be unique.

[code lang=”xml”]
<context-param>
<param-name>javax.faces.CONFIG_FILES</param-name>
<param-value>
/WEB-INF/faces-configXXXX.xml,
/WEB-INF/faces-configXXXXX.xml,
/WEB-INF/faces-configXXXXXX.xml
</param-value>
</context-param>

[/code]