JSF is a request-driven MVC web framework based on component-driven UI design model, using XML files called view templates or Facelets views. Requests are processed by the FacesServlet, which loads the appropriate view template, builds a component tree, processes events, and renders the response (typically HTML) to the client. The state of UI components (and some other objects) is saved at the end of each request (called stateSaving (note: transient true)), and restored upon next creation of that view. Several types of state-saving are available, including Client-side and Server-side state saving. Out of the box, JSF 1.x uses JavaServer Pages (JSP) for its display technology, but can also accommodate other technologies (such as XUL and Facelets). JSF 2 uses Facelets by default for this purpose. Facelets is a more efficient, simple, and yet more powerful view description language (VDL).

Managed Beans: A dependency injection system (easily interfaced with CDI, Spring, or Guice) – also called “Backing Beans” or “Page Beans”
A template-based component system, for rapid composite component creation – without the need for Java classes.
Built in Ajax support using  (since JSF v2.0).
Built in support for bookmarking & page-load actions.
Integration with the Unified Expression Language (EL), which is core to the function of JSF. Views may access managed bean fields and methods via EL:
A default set of HTML and web-application specific UI components
A server-side event model : For dispatching events and attaching listeners to core system functionality, such as “Before Render Response” or “After Validation”
State management, supporting: “request”, “session”, “application”, “flash”, and “view” scoped Java beans.
Two XML-based tag libraries (core and html) for expressing a JavaServer Faces interface within a view template (can be used with both JSP or Facelets)

One of the biggest mistakes you can make is to assume that Facelets is merely a replacement for Tiles. Facelets is much more than that: it’s a new way of thinking about JSF.

Java Server faces are the UI server based component framework with many features over other technologies >

> Developers work on UI components tag and not on bare HTML.
> Developers do not need to parse request & response > do not need to parse request
> JSF has different reneders kit > like HTMLRenderer, SVGRenderer (can be used for Phone), WMLRenderer
> J2ee standard
> JSF is represented as tree of UI component called view
> Developers can easily create custom component
> Inbuilt ajax support

Lifecycle of JSF

> Reconstruct the component from previous state
> Parse and coverters of the request
> Validations
> Event..
> Render the view
> Even handling


render: none
– execute: @this
– Space separated ids and @form also widely used
– event: action for buttons and links, valueChange for
textfields, text areas, select menus, list boxes
– onevent: none


May want to reuse list, so make component

(For validation only)

<!– Declare attributes here –>

<!– Create output here –>

Composite component with attributes:

– composite:interface Reminder: required is not properly
enforced in Mojarra 2.0.2 and earlier.

– composite:implementation
<h2>Message 1: “#{cc.attrs.msg1}”</h2>
<h2>Message 2: “#{cc.attrs.msg2}”</h2>
– Main page

– Result
Message 1: “Hello, world”
Message 2: “Hi”

Before: ActionListener was used
– For buttons. Form was automatically submitted when clicked
• Now: ValueChangeListener is used
– For combobox, listbox, radio button, checkbox, textfield, etc.
• Difference from ActionListener
– Form not automatically submitted
– Need to add JavaScript to submit the form
onclick=”submit()” or onchange=”submit()”
– Event incompatibility between Firefox and IE
• Firefox, Netscape, and Opera fire the onchange events when the
combobox selection changes, radio button is selected, or
checkbox is checked/unchecked
• Internet Explorer fires event when selection changes and
another GUI control receives the input focus
– onclick generally works consistently in current browsers. Older IE
versions behave differently. Test on multiple browsers!

Event listeners are used to handle events that
affect only the user interface
– Typically fire before beans are populated and validation is
• Use immediate=”true” to designate this behavior
– Form is redisplayed after listeners fire
• No navigation rules apply
• Action listeners
– Attached to buttons, hypertext links, or image maps
– Automatically submit the form
• Value change listeners
– Attached to radio buttons, comboboxes, list boxes, checkboxes,
textfields, etc.
– Require onclick=”submit()” or onchange=”submit()” to submit form
• Test carefully on all expected browsers

Page Templating :

Avoiding repetition in facelets pages
– OOP provides good reuse for Java code.
– But what about facelets code?
• Also want to avoid repeating nearly-identical code there
• Very common to have multiple pages that share the same
basic layout and same general look

Define a template file
– Content that will appear in all clients is entered directly
– Content that can be replaced in client files is marked with
ui:insert (with default values in case client does not
supply content)

Define a client file that uses the template
– Use ui:composition to specify the template file used
– Use ui:define to override content for each replaceable
section in template (marked in template with ui:insert)

Template file: