JSF 2.0 - a look through

JSF 2.0 session

Java servlet API's and

JSP - edit HTML pages with special tags - for dynamic java portions

uses a special servlet JSP container - handles JSP page views

• JSP container - translates requested jsp page to servlet code - compiled - executed immediatly
• subsequent invocation invoke runtime servlet for the page
• a change in JSP - triggers another translation, compilation and restart of runtime serlet

prob - JSP got cluttered with java code...

solution was separation of java code from presentation markup - MVC architecture

Some successful implementation include :

Apache struts - Action class - web accessible execution points for Java

View - through struts tags

Spring - Inversion of control container - clean separation through injection - business logic in OJO's no need of Java interfaces

JSF - emphasize on User interface oriented technology

Sun, Oracle, IBM, and BEA, met through the Java Community Process in May 2001 - went for a - comprehensive and detailed spec for building a Java EE thin client Web application

interface - resulted in JSR 127 - thus JSF - java server faces was born

JSf - combines MVC design + component based UI framework + uses existing markup and servlet technology

JSF design goals as per the spec 127

• Create a standard UI component framework - manage UI's connection with application behavior
• Define a set of simple lightweight Java base classes for UI components, Component states, input events etc
• common UI Components HTML form input elements
• javabeans model for dispatching events from client side UI controls - serverside application behavior
• API's for i/p validation, support for client side validation
• model for internationalization and localization of UI
• Web accessibility Initiative - provide o/p wit hooksfor accessibility
• automatic generation of output for target client.

1-3

JSf provides a set of UI components - that can be extented to achieve specialize dbehaviors - include

Core libraries

HTMl libraries

Core components - assigning validations

- converting input values

- loading resource bundles

HTML components - creates and renders HTML components

- input texts,links labels

- containers for printing tabular data

- panels of child components

4

"JavaBean model way of interacting with application data" -

Web accessible UI components - loosely coupled with server side Java POJO's -declared as Managed Beans

- Managed beans may be declared in XML - "faces-config.xml"

- via annotations

• Beans are coupled with UI using expression language like JSTL - EL with deferred evaluation -unified EL technology

• takes the responsibilty of evaluating the expression from the JSP engine - and evaluates it at appropriate time during the page lifecycle.
• support for expression that can set values and invoke methods
• support for JSTL iteration tags with deferred expression

<h:inputText id="name" value="#{student.name}"/>

during the initial request JSF implementaiton evaluates it during render response

for postback - the implementation evaluates it during -apply request values,process validations and update model

5

JSF request processing and event model supports for validation and conversion - when a form is submitted or UI component is accessed/manipulated

- built-in convertors and validatros

6

standard method to handle multilingual message bundle

Once the bundle is loaded the components render themselves automatically in appropriate language - based on incoming request locale

7,8

using pluggable rendering tecgnology - able to generate appropriate o/p depending on target client

Two major revisions on JSF -

• JSR 252 - introduced Unified EL

intergration b/w JSP and JTL

• JSR 314 - JSF 2.0

• Built-in support for templating - Facelets
• Support for Ajax
• Composite Componennts
• Bean validation - JSR 303
• Support for resource handling

Configuration for JavaServer Faces

• entry in web.xml - for Faces Controller Servlet
• • In servlet 3.0 - Glassfish v3 & Tomcat 7 - servlet is automaticaly configured to URL patterns: /faces/*,*.jsf and *.faces
• Optional faces-config.xml
• • configures all elements of JSF application.
  • located WEB-INF/
• JSF implementation libraries in WEB-INF/lib

After properly configuring ::

Contstruct Views using Facelets XHTML pages

- pages can be constructed using JSP - declaration language - but features of JSF 2.0 are limited for JSP

-pages are constructed using xhtml using JSF - enabled Facelet tag libraries

• <html xmlns=http://www.w3.org/1999/xhtml

xmlns:h=http://java.sun.com/jsf/html

xmlns:f="http://java.sun.com/jsf/core">

• To process form inputs - add a ,h:form tag. and subsequent form tags <h:inputText. <h:commandButton> within the <h:form>

eg)

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml"

xmlns:h="http://java.sun.com/jsf/html"

xmlns:f="http://java.sun.com/jsf/core">

<h:body>

<h:form>

<h2>A Simple JSF Page</h2>

<h:inputText value="helloworld"/>

<h:commandButton value="Click Here"/>

</h:form>

</h:body>

</html>

View Component Tree

img)

JSF Request Processing Life-cycle

img)

The sequence of events that are triggered during request to JSF page - JSF Request Processing Lifecycle - JSF Lifecycle

• first time a page is requested component tree is created in memory
• this component tree is cached if b/w request nothing alters the view
• on subsequent request tree is easily constituted
• form values are processed,validated and server side model updated
• completed response rendered back

The set of plumbing events automaticaly manage input events unlike struts CGI and PHP where developer writes code to process request & process results

- Removes the notion of manually processing incoming web request.

- Instead Web Developer need to rely on "JSF lifecycle to handle back-end plumbing automaticaly"

- Developer can use the event model to Jump in and do custom processing.

- Thus one will have to use :

-- lifecycle pahses such as :

applying request values

performing validation

interact with business logic/update model

perform navigation

rendering response -

- this makes the web application production quality..since most of the things the framework handles for you.

eg : the values in UI ocmponents are automaticaly updated to managed beans by bounding those two with a El expression

How JSF adhere to the "Model-View-Controller pattern"

img)

• clean separation b/w presentation code(View) and back-end business logic(Model)
• controller handles request - dispatches them with associated model data to the appropriate View.
• View created using UIComponents / Model consists of managed beans / bounded using EL

The controller is implemented as a Faces Servlet .

When request is received - process the request,creates JSF Context-contains application data - routes the client to appropriate view

Navigation Model

These rules used for routing in maintained in Faces-config.xml. and is known as navigation model.

The navigation model keep track of all navigation in entire JSF application.

Rules mentioned in faces-config.xml

<navigation-rule>

<from-view-id>/page1.xhtml</from-view-id>

<navigation-case>

<from-outcome>success</from-outcome>

<to-view-id>/page2.xhtml</to-view-id>

</navigation-case>

<navigation-case>

<from-outcome>failure</from-outcome>

<to-view-id>/page3.xhtml</to-view-id>

</navigation-case>

</navigation-rule>

• the outcome can be the return value of a method that is triggered when button is clicked

There are many mode for Navigation in JSF 2.0

• Rule based navigation - Explicit navigation
• Implicit navigation
• Conditional navigation
• Preemptive navigation
• Using a configurable Navigation handler

Creating Application in JSF

JSf - provides you with set of usable UI component + built in validation and conversion - JSF application is mainly assembling the UI with ready to use components

Facelets

Facelets have been incorporated into the core JSF specification in JSF 2.0.

It replaces JSP to be the View Declaration Language for JSF

• Server side templating - that allows composing the actual view from several page fragments- maximizes code reuses
• declared using xhtml
• enforce MVC architecture by disallowing Java code in markup language
• extensible tag library
• built for JSF
• support for unified EL
• In JSP web-page processed and rendered in progressive order while JSF has its own processing and rendering order - Facelets provide a better rendering model that resolves issues faced in using JSP with JSF.
• enables JSTL tags to be used with JSF.which was not possible/limited initially.
• The compilation process is faster than JSP compilation- bytecode is not actually generated and compiled when one first views a page

NB :- JSP is used to create static/dynamic content and "not component trees"

Its processing is linear top-bottom

while

In JSF component creation and rendering happen in separate phases

Facelet view technology focused on building component trees and interweaving content with JSF lifecycle.

eg)

<h:outputText value="Helloworld"/>

Goodmorning

o/p

Helloworld

Goodmorning

<h:panelGroup>

<h:outputText value="Helloworld"/>

Goodmorning

</h:panelGroup>

o/p

Goodmorning

Helloworld

ʘ all latest features of JSF are built into Facelets

Existing jsp:include and <%@include%> and c:import - using them in Jsf has following drawbacks

• parameters cannot be passed from host file to the included file
• <jsp:param> does'nt work for JSF as it stores content in page scope which "is not supported in JSF"

In facelets the EL awareness enables parameter passing.

Creating a portal page

In Facelet - we create a template - which define the basic layout of the page - with Facelets UI tag -

<ui:insert> - which defines areas in page that can be "overwritten".

<ui:composition> - the template attribute references the template we want to use for the page. All elements within the <ui:composition> will be evaluated by Facelets. And all components outside will be ignored.

<ui:decorate> - similiar to composition difference is it does not remove everything outside the tag.

<ui:include> - allows to include content from other documents

<ui:param> - tag is used to pass object as named variables b/w facelets.

--------------------------------------------------------------------------------------------------------

Nontemplating Facelets Tags

<ui:debug> - for debugging the component tree. "Ctrl+Shift+d" - displays a popup window displaying the component tree and scoped variables

<ui:remove> - used to comment out a portion of the page. useful in debugging

Commenting in xhtml.

<!--<h:outputText value="login user: #{user.testException}"/> -->

Inspite of the comment testException gets resolved..Except that it will not be rendered but remain as a comment in HTML.

To avoid this we cannot use the JSP comment <%-- --%>

The alternative in JSF is <ui:remove>. This turn out to be very useful in debugging.

or

one can set javax.faces.FACELETS_SKIP_COMMENTS to true in web.xml - to skip evaluation of comments.

<ui:component> - used to indicate that the piece of markup corresponds to a particular UIComponent instance in tree. Anything outside the markup is not included in view

<ui:fragment> - same as - it wrap a series of components under a single parent component before the parent is added to the tree. Can be used instead of the jstl if for selective rendering

Composite Component