Explore topic-wise InterviewSolutions in .

if you have the following URL: HTTP://your_server/your_app/product.jsf?id=777, you access the passing parameter id with the following lines of java code: 
FacesContext fc = FacesContext.getCurrentInstance(); 
String id = (String) fc.getExternalContext().getRequestParameterMap().get("id"); 
From the PAGE, you can access the same parameter using the predefined variable with NAME PARAM. For example, 
<H:outputText value="#{param['id']}" /> 
Note: You have to call the jsf page directly and using the servlet mapping.

if you have the following URL: http://your_server/your_app/product.jsf?id=777, you access the passing parameter id with the following lines of java code: 
FacesContext fc = FacesContext.getCurrentInstance(); 
String id = (String) fc.getExternalContext().getRequestParameterMap().get("id"); 
From the page, you can access the same parameter using the predefined variable with name param. For example, 
<h:outputText value="#{param['id']}" /> 
Note: You have to call the jsf page directly and using the servlet mapping.

Every JSF page as described has various components made with the help of JSF library. JSF may contain H:form, h:inputText, h:commandButton, etc. Each of these are rendered (translated) to HTML OUTPUT. This process is called encoding. The encoding procedure also ASSIGNS each component with a unique ID ASSIGNED by framework. The ID generated is random.

Every JSF page as described has various components made with the help of JSF library. JSF may contain h:form, h:inputText, h:commandButton, etc. Each of these are rendered (translated) to HTML output. This process is called encoding. The encoding procedure also assigns each component with a unique ID assigned by framework. The ID generated is random.

The data that is manipulated in form or the other is done by MODEL. The data presented to user in one form or the other is done by view. JSF is CONNECTS the view and the model. View can be depicted as shown by: 
<h:inputText value="#{user.name}"/> 
JSF acts as CONTROLLER by way of action processing done by the user or TRIGGERING of an event. For ex. 
<h:commandbutton value="Login" action="login"/> 
this button event will triggered by the user on Button press, which will invoke the login Bean as stated in the faces-config.xml file. Hence, it COULD be summarized as below: User Button Click -> form submission to server ->; invocation of Bean class ->; result thrown by Bean class caught be navigation rule ->; navigation rule based on action directs to specific page.

The data that is manipulated in form or the other is done by model. The data presented to user in one form or the other is done by view. JSF is connects the view and the model. View can be depicted as shown by: 
<h:inputText value="#{user.name}"/> 
JSF acts as controller by way of action processing done by the user or triggering of an event. For ex. 
<h:commandbutton value="Login" action="login"/> 
this button event will triggered by the user on Button press, which will invoke the login Bean as stated in the faces-config.xml file. Hence, it could be summarized as below: User Button Click -> form submission to server ->; invocation of Bean class ->; result thrown by Bean class caught be navigation rule ->; navigation rule based on action directs to specific page.

COMPONENT classes generally transfer the task of generating output to the renderer. All JSF components follow it. Render kit is a set of RELATED renderers. javax.faces.render.RenderKit is the class which represents the render kit. The default render kit CONTAINS renderers for html but its up to you to make it for other markup languages. Render kit can implement a skin (a look & feel).Render kit can target a specific device like phone, PC or markup LANGUAGE like HTML, WML, SVG. This is ONE of the best benefit of JSF because JSF doesn’t limit to any device or markup.

Component classes generally transfer the task of generating output to the renderer. All JSF components follow it. Render kit is a set of related renderers. javax.faces.render.RenderKit is the class which represents the render kit. The default render kit contains renderers for html but its up to you to make it for other markup languages. Render kit can implement a skin (a look & feel).Render kit can target a specific device like phone, PC or markup language like HTML, WML, SVG. This is one of the best benefit of JSF because JSF doesn’t limit to any device or markup.

JSP simply provides a Page which may contain markup, embedded Java code,and tags which ENCAPSULATE more complicated logic / html. JSF may use JSP as its template, but provides much more. This includes alidation, rich component MODEL and lifecycle, more sophisticated EL, separation of data, navigation handling, different VIEW technologies (instead of JSP), ability to provide more ADVANCED features such as AJAX, etc.

JSP simply provides a Page which may contain markup, embedded Java code,and tags which encapsulate more complicated logic / html. JSF may use JSP as its template, but provides much more. This includes alidation, rich component model and lifecycle, more sophisticated EL, separation of data, navigation handling, different view technologies (instead of JSP), ability to provide more advanced features such as AJAX, etc.

A RENDER kit defines how COMPONENT classes MAP to component tags that are appropriate for a particular client. The JavaServer Faces implementation INCLUDES a standard HTML render kit for rendering to an HTML client.

A render kit defines how component classes map to component tags that are appropriate for a particular client. The JavaServer Faces implementation includes a standard HTML render kit for rendering to an HTML client.

1.Restore View : A REQUEST comes through the FacesServlet controller. The controller examines the request and extracts the view ID, which is determined by the name of the JSP page. 
2. Apply request values : The purpose of the apply request values PHASE is for each component to retrieve its current state. The components must first be retrieved or created from the FacesContext object, followed by their values. 
3. Process validations : In this phase, each component will have its values validated against the APPLICATION's validation rules.
4. Update model values: In this phase JSF updates the actual values of the server-side model ,by updating the properties of your backing beans.
5. INVOKE application : In this phase the JSF controller invokes the application to handle Form submissions.
6. Render response : In this phase JSF displays the view with all of its components in their current state.

1.Restore View : A request comes through the FacesServlet controller. The controller examines the request and extracts the view ID, which is determined by the name of the JSP page. 
2. Apply request values : The purpose of the apply request values phase is for each component to retrieve its current state. The components must first be retrieved or created from the FacesContext object, followed by their values. 
3. Process validations : In this phase, each component will have its values validated against the application's validation rules.
4. Update model values: In this phase JSF updates the actual values of the server-side model ,by updating the properties of your backing beans.
5. Invoke application : In this phase the JSF controller invokes the application to handle Form submissions.
6. Render response : In this phase JSF displays the view with all of its components in their current state.

The six phases of the JSF application lifecycle are as follows (NOTE the EVENT processing at each phase):

1. Restore view 
2. Apply request values; process events 
3. Process VALIDATIONS; process events 
4. Update MODEL values; process events
5. INVOKE application; process events
6. Render response

The six phases of the JSF application lifecycle are as follows (note the event processing at each phase):

If no NAVIGATION rule matches a given ACTION, then the current PAGE is REDISPLAYED.

If no navigation rule matches a given action, then the current page is redisplayed.

Navigation RULES tells JSF implementation which page to send back to the browser after a FORM has been SUBMITTED. We can declare the page navigation as follows:
<naviagation-rule&GT;
<from-view-id>/index.jsp</from-view-id>
<navigation-case>
<from-outcome>login</from-outcome>
<to-view-id>/welcome.jsp</to-view-id>
</navigation-case>
</naviagation-rule>
This DECLARATION states that the login action navigates to /welcome.jsp, if it occurred inside /index.jsp.

Navigation rules tells JSF implementation which page to send back to the browser after a form has been submitted. We can declare the page navigation as follows:
<naviagation-rule>
<from-view-id>/index.jsp</from-view-id>
<navigation-case>
<from-outcome>login</from-outcome>
<to-view-id>/welcome.jsp</to-view-id>
</navigation-case>
</naviagation-rule>
This declaration states that the login action navigates to /welcome.jsp, if it occurred inside /index.jsp.

We can declare the message BUNDLE in TWO ways: 
(LET’s assume com.developersBookJsf.messages is the properties file)
1.  The simplest way is to include the following elements in faces-config.xml file:
<application>
<resource-bundle>
<base-name>com.developersBookJsf.messages</base-name>
<var>message</var>
</resource-bundle>
</application>
2.  Alternatively, you can add the f:loadBundle element to each JSF page that needs access to the bundle:
<f:loadBundle baseName = “com.developersBookJsf.messages” var=”message”/>

We can declare the message bundle in two ways: 
(Let’s assume com.developersBookJsf.messages is the properties file)
1.  The simplest way is to include the following elements in faces-config.xml file:
<application>
<resource-bundle>
<base-name>com.developersBookJsf.messages</base-name>
<var>message</var>
</resource-bundle>
</application>
2.  Alternatively, you can add the f:loadBundle element to each JSF page that needs access to the bundle:
<f:loadBundle baseName = “com.developersBookJsf.messages” var=”message”/>

The bean INSTANCE is configured in the faces-config.xml file:
<managed-bean>
<managed-bean-name>login</managed-bean-name>
<managed-bean-CLASS>com.developersBookJsf.loginBean</managed-bean-class>
<managed-bean-scope>request</managed-bean-scope>
</managed-bean>
This MEANS: Construct an object of the class com.developersBookJsf.loginBean, give it the name login, and keep it ALIVE for the duration of the request.

The bean instance is configured in the faces-config.xml file:
<managed-bean>
<managed-bean-name>login</managed-bean-name>
<managed-bean-class>com.developersBookJsf.loginBean</managed-bean-class>
<managed-bean-scope>request</managed-bean-scope>
</managed-bean>
This means: Construct an object of the class com.developersBookJsf.loginBean, give it the name login, and keep it alive for the duration of the request.

JSF application typically uses JSP pages to represent views. JSF provides useful special tags to enhance these views. Each TAG gives rise to an associated component.

JSF (Sun IMPLEMENTATION) provides 43 tags in two STANDARD JSF tag libraries:

•JSF Core Tags LIBRARY.
•JSF Html Tags Library.

JSF application typically uses JSP pages to represent views. JSF provides useful special tags to enhance these views. Each tag gives rise to an associated component.

JSF (Sun Implementation) provides 43 tags in two standard JSF tag libraries:

•JSF Core Tags Library.
•JSF Html Tags Library.

SP-EL :

• In JSP-EL the value expressions are delimited by ${…}.
• The ${…} delimiter DENOTES the IMMEDIATE EVALUATION of the expressions, at the time that the application server PROCESSES the page.

JSF-EL :

• In JSf-EL the value expressions are delimited by #{…}.
• The #{…} delimiter denotes deferred evaluation. With deferred evaluation ,the application server retains the expression and evaluates it whenever a value is NEEDED.

SP-EL :

JSF-EL :

JSF supports three Bean Scopes. viz.,
•Request Scope: The request scope is short-lived. It starts when an HTTP request is SUBMITTED and ends when the response is sent back to the client.
•Session Scope: The session scope persists from the time that a session is ESTABLISHED until session termination.
•Application Scope: The application scope persists for the entire duration of the WEB application. This scope is shared AMONG all the requests and sessions.

JSF supports three Bean Scopes. viz.,
•Request Scope: The request scope is short-lived. It starts when an HTTP request is submitted and ends when the response is sent back to the client.
•Session Scope: The session scope persists from the time that a session is established until session termination.
•Application Scope: The application scope persists for the entire duration of the web application. This scope is shared among all the requests and sessions.

Bean Scope typically holds BEANS and other OBJECTS that NEED to be available in the DIFFERENT components of a web APPLICATION.

Bean Scope typically holds beans and other objects that need to be available in the different components of a web application.

In a simple Web application, a domain object model can be used across all tiers, however, in a more complex Web application, a separate view object model needs to be used. Domain object model is about the business object and should BELONG in the business-LOGIC tier. It contains the business data and business logic associated with the SPECIFIC business object. A view object contains presentation-specific data and behavior. It contains data and logic specific to the presentation tier.

In a simple Web application, a domain object model can be used across all tiers, however, in a more complex Web application, a separate view object model needs to be used. Domain object model is about the business object and should belong in the business-logic tier. It contains the business data and business logic associated with the specific business object. A view object contains presentation-specific data and behavior. It contains data and logic specific to the presentation tier.

Domain object MODEL is about the business object and should belong in the business-LOGIC tier. It contains the business DATA and business logic associated with the specific business object.

Domain object model is about the business object and should belong in the business-logic tier. It contains the business data and business logic associated with the specific business object.

A view object is a MODEL object used specifically in the presentation tier. It contains the data that must display in the view LAYER and the logic to VALIDATE user input, handle events, and interact with the business-logic tier. The BACKING BEAN is the view object in a JSF-based application. Backing bean and view object are interchangeable terms.

A view object is a model object used specifically in the presentation tier. It contains the data that must display in the view layer and the logic to validate user input, handle events, and interact with the business-logic tier. The backing bean is the view object in a JSF-based application. Backing bean and view object are interchangeable terms.

Backing Beans :

• A backing bean is any bean that is referenced by a form.
• Backing Beans should be defined only in the request scope.

Managed Beans :

• A managed bean is a backing bean that has been registered with JSF (in faces-config.xml) and it automatically created (and optionally initialized) by JSF when it is needed.
• The ADVANTAGE of managed beans is that the JSF framework will automatically create these beans, optionally initialize them with parameters you specify in faces-config.xml,
• The managed beans that are created by JSF can be stored WITHIN the request, session, or application scopes.

Backing Beans should be defined in the request scope, exist in a one-to-one relationship with a particular page and hold all of the page specific event handling code.In a real-world SCENARIO, several PAGES may NEED to share the same backing bean behind the scenes.A backing bean not only contains view data, but also behavior related to that data.

Backing Beans :

Managed Beans :

Backing Beans should be defined in the request scope, exist in a one-to-one relationship with a particular page and hold all of the page specific event handling code.In a real-world scenario, several pages may need to share the same backing bean behind the scenes.A backing bean not only contains view data, but also behavior related to that data.

Backing BEANS are merely a convention, a subtype of JSF MANAGED Beans which have a very particular purpose. There is NOTHING SPECIAL in a Backing BEAN that makes it different from any other managed bean apart from its usage.

Backing Beans are merely a convention, a subtype of JSF Managed Beans which have a very particular purpose. There is nothing special in a Backing Bean that makes it different from any other managed bean apart from its usage.

JavaBean objects managed by a JSF implementation are called managed BEANS. A managed bean DESCRIBES how a bean is created and managed. It has nothing to do with the bean's FUNCTIONALITIES

JavaBean objects managed by a JSF implementation are called managed beans. A managed bean describes how a bean is created and managed. It has nothing to do with the bean's functionalities

JavaServer Faces applications are just like any other Java web application. They RUN in a servlet container, and they typically contain the following:

• JAVABEANS components containing application-specific functionality and data.
• Event listeners.
• Pages, such as JSP pages.
• Server-side helper classes, such as database access beans.

In addition to these items, a JavaServer Faces application ALSO has:

• A custom tag library for rendering UI components on a page.
• A custom tag library for representing event handlers, validators, and other actions.
• UI components represented as stateful objects on the server.
• BACKING beans, which define properties and functions for UI components.
• Validators, converters, event listeners, and event handlers.
• An application CONFIGURATION resource file for configuring application resources.

JavaServer Faces applications are just like any other Java web application. They run in a servlet container, and they typically contain the following:

In addition to these items, a JavaServer Faces application also has:

A TYPICAL JSF application consists of the following parts:

•JavaBeans components for managing application state and behavior.
•Event-driven development (via listeners as in traditional GUI development).
•PAGES that REPRESENT MVC-style VIEWS; pages reference view roots via the JSF component TREE.

A typical JSF application consists of the following parts:

•JavaBeans components for managing application state and behavior.
•Event-driven development (via listeners as in traditional GUI development).
•Pages that represent MVC-style views; pages reference view roots via the JSF component tree.

The main implementations of JavaServer FACES are:

•Reference Implementation (RI) by Sun Microsystems.
•Apache MYFACES is an open source JavaServer Faces (JSF) implementation or run-time.
•ADF Faces is ORACLE’s implementation for the JSF STANDARD.

The main implementations of JavaServer Faces are:

•Reference Implementation (RI) by Sun Microsystems.
•Apache MyFaces is an open source JavaServer Faces (JSF) implementation or run-time.
•ADF Faces is Oracle’s implementation for the JSF standard.

In a nutshell, Faces has the following advantages over Struts:

• Eliminated the NEED for a Form Bean
• Eliminated the need for a DTO Class
• Allows the use of the same POJO on all Tiers because of the Backing Bean

The primary advantages of Struts as compared to JavaServer Faces technology are as follows: 

1. Because Struts is a web application framework, it has a more sophisticated controller architecture than does JavaServer Faces technology. It is more sophisticated partly because the application developer can access the controller by creating an Action object that can integrate with the controller, whereas JavaServer Faces technology does not allow access to the controller. In ADDITION, the Struts controller can do things like access control on each Action based on user roles. This functionality is not provided by JavaServer Faces technology.
2. Struts includes a powerful layout management framework, called Tiles, which allows you to create templates that you can reuse across multiple pages, thus enabling you to establish an overall look-and-feel for an application.
3. The Struts validation framework includes a larger set of standard validators, which automatically generate both server-side and client-side validation code based on a set of rules in a configuration file. You can also create custom validators and easily include them in your application by adding definitions of them in your configuration file.

The greatest advantage that JavaServer Faces technology has over Struts is its flexible, extensible UI component model, which includes: 

1. A standard component API for specifying the STATE and BEHAVIOR of a wide range of components, including simple components, such as input fields, and more complex components, such as scrollable data tables. Developers can also create their own components based on these APIs, and many third parties have already done so and have made their component LIBRARIES publicly available.
2. A separate rendering model that defines how to render the components in various ways. For example, a component used for selecting an item from a list can be rendered as a menu or a set of radio buttons.
3. An event and listener model that defines how to handle events generated by activating a component, such as what to do when a user clicks a button.
4. Conversion and validation models for converting and validating component data.

In a nutshell, Faces has the following advantages over Struts:

The primary advantages of Struts as compared to JavaServer Faces technology are as follows: 

The greatest advantage that JavaServer Faces technology has over Struts is its flexible, extensible UI component model, which includes: 

The major BENEFITS of JavaServer Faces technology are:

• JavaServer Faces architecture makes it easy for the developers to use. In JavaServer Faces technology, user interfaces can be created easily with its built-in UI component LIBRARY, which handles most of the complexities of user interface management.
• Offers a clean separation between BEHAVIOR and presentation.
• Provides a rich architecture for managing component state, processing component data, validating user input, and handling events.
• Robust event handling mechanism.
• Events easily tied to server-side code.
• Render kit support for different clients.
• Component-level control over statefulness.
• Highly 'pluggable' - components, view handler, etc.
• JSF also supports internationalization and ACCESSIBILITY.
• Offers multiple, standardized vendor IMPLEMENTATIONS.

The major benefits of JavaServer Faces technology are:

A server side USER interface component framework for Java technology-based web applications. JavaServer Faces (JSF) is an industry standard and a framework for building component-based user interfaces for web applications. 

JSF contains an API for representing UI 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. 

A server side user interface component framework for Java technology-based web applications. JavaServer Faces (JSF) is an industry standard and a framework for building component-based user interfaces for web applications. 

JSF contains an API for representing UI 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.