Petr Blaha

Sun Microsystems, Inc

Development of Web Applications based on JSF

Topics

Evolution of Web Application Framework

What is and why JSF?

JSF design goals

Quick overview on JSF architecture, concepts, and features

Developer roles (in Web app development)

Managed Beans

Page navigation

JSF next

These are the topics we will talk about in this presentation. The goal of this presentation is to go over the basic features of JSF so that you get some clear sense on how to build and deploy a basic JSF application.

Evolution of Web Application Design Architecture

Now let's talk about the evolution of web application design architecture.

Evolution of MVC Architecture

No MVC

MVC Model 1 (Page-centric)

MVC Model 2 (Servlet-centric)

Web application frameworks

JSF, Struts, Facelets

Now when we talk about Web application framework, we are basically talking about the evolution of MVC architecture, which stands for Model, View, and Controller.

So in the beginning, we used no MVC. Then we had JSP Model1 and Model 2 architecture. And people came up with so called Web application frameworks such as Apache Strut based on Model 2 architecture. And finally we are at the phase there will be a standard based Web application framework.

So let's talk about these in a bit more detail.

Model 1
(Page-Centric Architecture)

Let's see Model 1 architecture first. The model 1 architecture is page-centric architecture.

Model 1 Architecture (Page-centric)

Request

1

JSPpages

Java Bean

Response

4

2

3

BROWSER

Servlet
Container

Enterprise Information Systems (EIS)

The literature on Web-tier technology in the J2EE platform frequently uses the terms Model 1 and Model 2 without explanation. This terminology stems from early drafts of the JSP specification, which described two basic usage patterns for JSP pages. While the terms have disappeared from the specification document, they remain in common use.

Model 1 and Model 2 simply refer to the absence or presence (respectively) of a controller servlet that dispatches requests from the client tier and selects views.

A Model 1 architecture consists of a Web browser directly accessing Web-tier JSP pages. The JSP pages access Web-tier JavaBeans that represent the application model. And the next view to display (JSP page, servlet, HTML page, and so on) is determined either by hyperlinks selected in the source document or by request parameters.

In a Model 1 architecture, view selection is decentralized, because the current page being displayed determines the next page to display. In addition, each JSP page or servlet processes its own inputs (parameters from GET or POST). And this is hard to maintain, for example, if you have to change the view selection, then several JSP pages need to be changed.

In some Model 1 architectures, choosing the next page to display occurs in scriptlet code, but this usage is considered poor form.

Page-centric Architecture

This picture shows what I mentioned in the previous slide. In page-centric architecture, the next page selection is determined by each JSP page. So the page selection is distributed. (On the other hand, servlet-centric approach, which we will learn later, the page selection will be handled by a single servlet which is a centralized approach in terms of page selection.) The same thing can be said about input handling. Here each page has to handle input handling such as translation or transformation. So controller function is also distributed among different pages.

Model 2
(Servlet-Centric Architecture)

Now let's talk about model 2 architecture which we call servlet-centric architecture.

Model 2 Architecture (Servlet-centric)

Request

1

(Controller)
Servlet

(View)
JSP

Response

5

3

4

BROWSER

Servlet Container

(EIS)

Redirect

2

(Model)
Java Bean

Instantiate

MVC Design Pattern

A Model 2 architecture introduces a controller servlet between the browser and the JSP pages.

The controller centralizes the logic for dispatching requests to the next view based on the request URL, input parameters, and application state. The controller also handles view selection, which de-couples JSP pages and servlets from one another.

Model 2 applications are easier to maintain and extend, because views do not refer to each other directly. The Model 2 controller servlet provides a single point of control for security and logging, and often encapsulates incoming data into a form usable by the back-end MVC model.

For these reasons, the Model 2 architecture is recommended for most web applications.

Why Model 2 Architecture (instead of Model 1)?

What if you want to present different JSP pages depending on the data you receive?

JSP technology alone even with JavaBeans and custom tags (Model 1) cannot handle it well

Solution

Use Servlet and JSP together (Model 2)

Servlet handles initial request, partially process the data, set up beans, then forward the results to one of a number of different JSP pages

I mentioned in previous slide, under Model 1 architecture, a view selection is done by each JSP page. And this poses a maintenance problem.

Now there is another limitation of using Model 1 architecture. In many cases, you want to select JSP pages depending on the data you received from the client. This means there has to be some software entity that handles the processing of the data and then selection of the view. And JSP is not really a good place that you can put this programming logic.

So what is the solution? Model 2 architecture. In Model 2 architecture, both servlet and JSP are used together. In other words, Servlet handles initial request, partially process the data, then forward the results to different JSP pages.

What is & Why JSF?

So let's talk about what is and why JSF first.

JavaServer Faces (JSF) Framework Is

A server side user interface (UI) component framework for Java technology-based web applications.

Drag-and-drop UI components to build a web Application.

In short, JSF is a server side user interface component framework for Java technology based Web applications.

Please note that it is server side instead of client side framework. What this means is that, in JSF architecture, many things that are related to UI management are handled at the server instead of at client side. Of course, the prime example of client side UI framework is Swing.

Please also note that JSF is a UI component framework. What this means is, under JSF architecture, UI is handled by a set of UI components as we will learn later on. The concept of UI component is very important in understanding JSF.

What is JSF?

Next generation Web application framework based on component model

UI Components

Events-based interaction model

Back-end-data integration

Designed to be leveraged by tools (as opposed to be used by developers directly)

Example: NetBeans Visual Web Pack (VWP)

You can still create JSF application by writing JSP pages yourself

In a bit more technical definition, JSF is a specification and reference implementation for Web application development framework. And the specification defines various things such as UI component model, event and listener model, validator model, back-end data integration model.

The goal of JSF is to allow tool vendors to provide easy to use tools leveraging JSF underneath so that developers can build Web applications using, for example, drag and drop model as they do in standalone Swing based applications. And a good example of the tool that leverages JSF underneath is Sun Java Studio Creator.

Why JSF?

Higher abstraction for Web application development

Event-driven programming model (as opposed to HTTP request/response programming model)

MVC for web applications

Extensible Component and Rendering architecture

Support for client device independence

Standard

Huge vendor and industry support

Now let's talk about value propositions of JSF. You can consider JSF provides the MVC based Web application framework. Again it provides clean separation of roles as we will talk about later in this presentation. JSF is easy to use. And it provides UI component framework which is extensible. It also provides rendering architecture in which UI components can be associated with multiple renderers. JSF is also designed with multiple client types in mind.

Why JSF? (Continued)

Offers finer-grained separation of behavior and presentation than JSP

Component-specific event handling

UI elements as stateful objects on the server

UI-component and Web-tier concepts without limiting you to a particular view technology (markup language)

Can work with any presentation technology including JSP

Facelets is getting popular

One of the greatest advantages of JavaServer Faces technology is that it offers a clean separation between behavior and presentation. Web applications built with JSP technology partially achieve this separation. However, a JSP application cannot map HTTP requests to component-specific event handling or manage UI elements as stateful objects on the server. JavaServer Faces technology allows you to build Web applications that implement finer-grained separation of behavior and presentation traditionally offered by client-side UI architectures.

The separation of logic from presentation also allows each member of a Web application development team to focus on their piece of the development process, and provides a simple programming model to link the pieces together. For example, Page Authors with no programming expertise can use UI component tags to link to application code from within a Web page without writing any scripts.

Another important goal of JavaServer Faces technology is to leverage familiar UI-component and Web-tier concepts without limiting you to a particular scripting technology or markup language. While JavaServer Faces technology includes a JSP custom tag library for representing components on a JSP page, the JavaServer Faces technology APIs are layered directly on top of the Servlet API. This layering of APIs enables several important application use-cases such as: using another presentation technology besides JSP pages, creating your own custom components directly from the component classes, and generating output for different client devices.

Most importantly, JavaServer Faces technology provides a rich architecture for managing component state, processing component data, validating user input, and handling events.

JSF versus Struts?

JSP and Servlet

No built-in UI component model

A few words on Struts first

I am not saying you should not use Struts

Struts and JSF can be used together

Struts

No built-in UI component model

No built-in event model for UI components

No built-in state management for UI components

No built-in support of multiple renderers (Struts is more or less tied up with HTML)

So in summary, why do we need JSF when we have Servlet and JSP? Furthermore, why do we need JSF when we have a popular web application frameworks such as Struts?

As was mentioned in previous slide, JSP and Servlet do not provide built-in UI component model.

What about Struts? Struts is designed with a different focus. The focus of Struts is to provide a controller framework while the focus of JSF is to provide UI component framework. So Struts does not provide the built-in UI component model. And because of that, it does not support UI component event model, nor state management of UI components, and because Struts is more or less tied up with HTML, it does not support the independence between UI components and a particular renderer.

JSF Design Goals

JavaServer Faces Must Be ...

Tool friendly

Client device / protocol neutral

Usable with JavaServer Pages (JSP)

Usable without JSP

Useful in the context of HTML and today's browsers

Extensible

Facelets, Seam, etc.

When JSF expert group started working on JSF specification, they had a few things in mind.

First, JSF should be tool friendly. If you think about how developers are building Swing application, they don't write their apps directly using Swing APIs. Instead, they would use an IDE in which they can do drag and dropping UI widgets. And the JSF expert group expect the same thing for building Web applications. They expect tool vendors will provide a way in which developers can drag and drop UI widgets for building Web applications.

The next goal is to make JSF to be client device and protocol neutral. That is, there has to be a clean separation between UI component model and how UI components are rendered to a particular client using a particular protocol. Of course, HTML browser using HTTP protocol is the most pervasive form of client device and protocol and they should be well supported. But the point is the UI component model should be able to accommodate other client types and protocols easily as they come.

Given that JSP is the most popular presentation technology, JSF should be able to work well with JSP but JSF should also work well with other presentation technologies.

How the JSF Specification Fits In

JSF AppServlets (2.3)JSP (1.2)JSF APIJSF TagsJSF AppThis picture shows where JSF fits in with other Web-tier technologies. First of all, just like all the other Web-tier technologies, JSF is built over Servlet. In fact, most of JSF APIs are built over Servlet directly. JSF also leverages JSP as well. And JSF custom tags which we will talk about in detail later on are based on JSP custom tag technology.

Quick Overview on JSF Architecture,Concept, & Features

Now I would like to spend the next 10 or so minutes giving you a quick overview of JSF architecture, concept, and features. Again we will go over these in detail later on. But given that all the features of JSF are somewhat interrelated, it is good to know the big picture first.

JSF is a UI Framework for Java Web Applications

Client

Server

UI

request

Response

(events)

(markup)

As I mentioned, JSF provides User interface framework, which runs on the service side.

Let's say a client makes a request. The request goes across the network to the server, where JSF framework builds up UI representation and renders back to the client in whatever mark up language that is appropriate to the client.

The user interacts with that page, and submit a request to the server for processing. The JSF framework then interprets the request parameters, and decode them and converts them into events and dispatch them to event handling logic.

JSF Architecture

HTML RenderKit

AppBackendDesktopBrowserPhoneFrontctrlJSF Page

JSF Page

WML

HTML

Server

WML RenderKit

This picture shows JSF architecture in a somewhat simplified manner.

Just like any other MVC-based architecture, JSF architecture has its own Front controller called FacesServlet. The role of this controller is basically a gatekeeper.

As we will learn later on, a JSF page is made of a tree of UI components. These UI components can be associated with backend model objects called backing beans. These backing beans handle application logic (or sometimes called business logic) handling.

When a page has to be rendered to a particular client type, whether the client type is a HTML browser running on a desktop or WML browser running on a wireless phone, a particular renderer is used for displaying the data maintained in the UI components. In other words, a same UI component is used for displaying information on different client types using different protocols.

Important Basic Capabilities

Extensible UI component model

Flexible rendering model

Event handling model

Validation framework

Basic page navigation support

Internationalization

Accessibility

So just to repeat the important JSF features and capabilities here one more time, JSF UI component model is extensible. That is, you as a developer can use the built-in UI components that come with a typical JSF implementation or you can extend them. JSF also provides flexible rendering model as was mentioned. That is, UI components in JSF are not tied with a particular rendering technology such as HTML. This means any rendering technology can be used for displaying information maintained in the UI components.

JSF also supports event handling model. For example, when you click on a UI component on a JSF page, it will generate an event and any server side programs which registered to receive event notifications will be notified.

JSF also supports page navigation through a configuration file. In this sense, this is quite similar with Struts.

JSF also supports internationalization and accessibility.

Key JSF Concepts

UIComponent

Render-independent characteristics

Base class with standard behaviors

Standard UIComponent Subclasses:

UICommand, UIForm, UIGraphic, UIInput, UIOutput, UIPanel,

FacesEvent

Base class for request and application events

Validator

Base class for standard and application defined validators

So let's go over some of the key JSF concepts. Again, we talked about these concepts already a bit.

First, the concept of UI component is extremely important for you to understand. I would say that if you understand the concept of UI component, you understand 90% of JSF architecture.

Key JSF Concepts

Converter

Plug-in for String-Object conversion

FacesContext

Servlet request, response, session

JSF request, response trees

Model reference expression evaluators

Syntax similar to the expression language of the JSP Standard Tag Library (JSTL) 1.x

Primary interface between components and the data provided by (or to) the application

Key JSF Concepts

Renderer

Converts components to and from a specific markup language

Supports render-dependent attributes on components

May support more than one component type

RenderKit

Library of Renderers

Extensible at runtime

Basic HTML RenderKit is part of the specification

Relationship to Other JSRs

JSF 1.1 is based on:

Servlet 2.3 (JSR-53)

JSP 1.2 (JSR-53)

JSF must be synergistic with:

JSTL 1.0 (JSR-52)

Portals (JSR-168)

JSF 1.2 (JavaEE5)

JSF 2.0 (JavaEE6)

Developer Roles

JSF Developer Roles

Page Author

Application Developer

ComponentDeveloper

Tools Developer

JSF Implementor/Extender

Application

Extensions

Because of the division of labor enabled by the JavaServer Faces technology design, JavaServer Faces application development and maintenance can proceed quickly and easily.

The members of a typical development team are those mentioned in the picture above. In many teams, individual developers play more than one of these roles, however, it is still useful to consider JavaServer Faces technology from a variety of perspectives based on primary responsibility.

So let's talk about each of these roles in the following slides.

Roles Definition

Page Author Creates the user interface of a web application

Familiar with markup language(s) to be used

Assembler of prebuilt components

Uses Drag and drop

Component Writer Creates reusable components, renderers, and libraries

Components Render-independent properties

Renderers Render-dependent properties

Page Authors, who use a markup language, like HTML, author pages for Web applications. When using the JavaServer Faces technology framework, page authors will most likely use the tag library exclusively. They play the role of assembler of prebuilt custom tags typically by using drop and drop IDE like Sun Java Studio Creator. A typical custom tags is, as we will see later on, in the form of combination of a UI component and a renderer.

Component Writers, who have user-interface programming experience and prefer to create custom components using Java programming language. These people can create their own components directly from the component classes, or they can extend the standard components provided by JavaServer Faces technology. They might also create renderers for a particular client type. JSF implementation comes with HTML renderers.

Roles Definition

Application Developer Creates the server-side functionality of a web application not directly related to the user interface

Business logic components implemented in standard J2EE ways (EJBs, JavaBeans, Connectors)

Persistence tier components implemented in standard J2EE ways (EJBs, JDBC, Connectors)

Model data exposed to user interface via JavaBean programming model

Validator, Convertor, Event handler

Application Developers are people who program the server side objects called backing beans or model objects, the event handlers, the validators, and the page navigation.

Application developers can also provide the extra helper classes.

Roles Definition

Tool Provider Creates tools to assist page authors, component writers, and application developers

GUI-oriented page development tools

IDEs to facilitate creation of components

Application generators (from high level description)

Web application frameworks that utilize JSF components for their user interface

Example: NetBeans Visual Web

JSF Implementor Provides runtime environment to execute JSF webapps

J2EE SDK 1.4

Tools Vendors provide tools that leverage JavaServer Faces technology to make building server-side user interfaces even easier.

ApplicationConfiguration

Application Configuration File

XML file for configuring resources required at application startup time

navigation rules, converters, validators, render kits

Usually named as faces-config.xml

A tag must enclose all of the other declarations

....

The application configuration file is an XML file, usually named faces-config.xml, whose purpose is to configure resources for an application. These resources include: navigation rules, converters, validators, render kits, and others.

The application configuration file must be valid against the DTD located at http://java.sun.com/dtd/web-facesconfig_1_0.dtd.

faces-config.xml

en

de

fr

es

Here is the first part of faces-config.xml file of the guessNumber application.

faces-config.xml

...

/greeting.jsp

...

...

/response.jsp

...

...

UserNumberBean

...

This is the continuation of the faces-config.xml file of the guessNumber application. Please note that the configuration file contains one or more elements and zero or more elements.

Application Configuration File

You can have more than one application configuration file

There are three ways that you can make these files available to the application]

A resource named /META-INF/faces-config.xml in any of the JAR files in the Web application's /WEB-INF/lib directory

A context init parameter, javax.faces.application

A resource named faces-config.xml in the /WEB-INF/ directory of your application (most common)

You can have more than one application configuration file, and there are three ways that you can make these files available to the application. The JavaServer Faces implementation finds the file or files by looking for:

* A resource named /META-INF/faces-config.xml in any of the JAR files in the Web application's /WEB-INF/lib directory. If a resource with this name exists, it is loaded as a configuration resource. This method is practical for a packaged library containing some components and renderers. The demo-components.jar, located in /jsf/samples uses this method.* A context init parameter, javax.faces.application.CONFIG_FILES that specifies one or more (comma-delimited) paths to multiple configuration files for your Web application. This method will most likely be used for enterprise-scale applications that delegate the responsibility for maintaining the file for each portion of a big application to separate groups.* A resource named faces-config.xml in the /WEB-INF/ directory of your application if you don't specify a context init parameter. This is the way most simple applications will make their configuration files available.

Application Class

When an application starts up, the JSF implementation creates a single instance of the Application class

Is automatically created for each application

FacesContext.getApplication()

To access resources registered with the application, you use the Application class, which is automatically created for each application. The Application class acts as a centralized factory for resources that are defined in the XML file.

When an application starts up, the JavaServer Faces implementation creates a single instance of the Application class and configures it with the information you configure in the application configuration file.

When you need to access the Application instance, the easiest way to retrieve it is to call the getApplication method of the FacesContext instance.

Backing Bean(Model Object)Management

What are Backing Beans?

Server-side objects associated with UI components used in the page

Define UI component properties, each of which is bound to

a component's value or

a component instance

Can also define methods that perform functions associated with a component, which include validation, event handling, and navigation processing.

A typical JavaServer Faces application includes one or more backing beans, which are server-side objects associated with UI components used in the page. A backing bean defines UI component properties, each of which is bound to either a component's value or a component instance. A backing bean can also define methods that perform functions associated with a component, which include validation, event handling, and navigation processing.

Why Backing Beans?

Separation of Model from View (MVC)

Model handles application logic and data: Backing Beans are Model objects

View handles presentation: UI components

Another critical function of web applications is proper management of resources. This includes separating the definition of UI component objects from objects that perform application-specific processing and hold data. It also includes storing and managing these object instances in the proper scope.

How to Specify Backing Beans in JSP page?

A page author uses the JavaServer Faces expression language (JSF EL) to bind a component's value or its instance to a backing bean property

JSF EL is in the form of "#{...}"

A page author also uses the JSF EL to refer to the backing-bean methods that perform processing for the component

A page author uses the JavaServer Faces expression language (JSF EL) to bind a component's value or its instance to a backing bean property. The expression must be enclosed in the curly brackets of "#{}". A page author also uses the JSF EL to refer to the backing-bean methods that perform processing for the component.

Example: Binding Component Value to Backing Bean

userNo component's value is bound to the UserNumberBean.userNumber backing-bean property

For example, consider the inputText tag from the greeting.jsp page of the guessNumber application:

This tag binds the userNo component's value to the UserNumberBean.userNumber backing-bean property.

faces-config.xml

The "backing file" bean that backs up the guessNumber webapp

UserNumberBean

guessNumber.UserNumberBean

session

minimum

int

0

maximum

int

10

Here is the new greeting.jsp page with the validator tags (minus the surrounding HTML):

Page Navigation

Define Page Navigation

Application developer responsibility

Navigation rules are defined in the application configuration file

Navigation rules

Determine which page to go to after the user clicks a button or a hyperlink

Another responsibility that the application developer has is to define page navigation for the application, which involves determining which page to go to after the user clicks a button or a hyperlink. The JavaServer Faces navigation model, new for this release, is explained in Navigation Model. Navigating Between Pages (page 890) explains how to define the navigation rules for an entire application.

The application developer defines the navigation for the application in the application configuration file, the same file in which managed beans are declared.

Navigation Rule 1

The decision rule used by the NavigationHandler to

determine which view must be displayed after the

current view, greeting.jsp is processed.

/greeting.jsp

Indicates to the NavigationHandler that the response.jsp

view must be displayed if the Action referenced by a

UICommand component on the greeting.jsp view returns

the outcome "success".

success

/response.jsp

Each navigation-rule defines how to get from one page (specified in the from-tree-id element) to the other pages of the application. The navigation-rule elements can contain any number of navigation-case elements, each of which defines the page to open next (defined by to-tree-id) based on a logical outcome (defined by from-outcome).

Navigation Rule 2

The decision rules used by the NavigationHandler to

determine which view must be displayed after the

current view, response.jsp is processed.

/response.jsp

Indicates to the NavigationHandler that the greeting.jsp

view must be displayed if the Action referenced by a

UICommand component on the response.jsp view returns

the outcome "success".

success

/greeting.jsp

Each navigation-rule defines how to get from one page (specified in the from-tree-id element) to the other pages of the application. The navigation-rule elements can contain any number of navigation-case elements, each of which defines the page to open next (defined by to-tree-id) based on a logical outcome (defined by from-outcome).

Navigation Rule

defines how to get from one page (specified in the from-tree-id element) to the other pages of the application

can contain any number of elements

defines the page to open next (defined by to-tree-id) based on a logical outcome (defined by from-outcome)

(just to repeat what I just said in the previous slide)

Each navigation-rule defines how to get from one page (specified in the from-tree-id element) to the other pages of the application. The navigation-rule elements can contain any number of navigation-case elements, each of which defines the page to open next (defined by to-tree-id) based on a logical outcome (defined by from-outcome).

Where can Outcome come from?

Outcome can be defined by the action attribute of the UICommand component that submits the form

action attribute can be a string or action method (#{.})

The outcome can be defined by the action attribute of the UICommand component that submits the form, as it is in the guessNumber example:

The outcome can also come from the return value of the invoke method of an Action object. The invoke method performs some processing to determine the outcome. One example is that the invoke method can check if the password the user entered on the page matches the one on file. If it does, the invoke method could return "success"; otherwise, it might return "failure". An outcome of "failure" might result in the logon page being reloaded. An outcome of "success" might result in the page displaying the user's credit card activity opening.

JSF 2.0

tigther integration with AJAX

skinning and theming

better view description technology (aka Facelets)

minimalization of 'xml hell'

Demo

NetBeans IDE

JSF + JPA

JSF D&D approach

Petr Blaha

Sun Microsystems, Inc

Development of Web Applications based on JSF

Page

Speaker Presentation Name

Sun Microsystems, Inc.

Click to edit the title text format

Click to edit the outline text format

Second Outline Level

Exact File Name

4/27/08

Page

Click to edit the title text format

Presenters Name

Presenters Title

Presenters Company

Click to edit the notes format

Page