javaserver faces (jsf) overview -...

1

1

JavaServer FacesJavaServer Faces(JSF) Overview(JSF) Overview

OK, this session is about JSF basics. As some of you probably know, JSF is an extremely important Java technology going forward.

2

2

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

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.

3

3

Evolution of Web Evolution of Web Application Design Application Design

ArchitectureArchitecture

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

4

4

Evolution of MVC Architecture

1.No MVC2.MVC Model 1 (Page-centric)3.MVC Model 2 (Servlet-centric)4.Web application frameworks

? Struts

5.Standard-based Web application framework? JavaServer Faces (JSR-127)

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.

5

5

Model 1(Page-Centric Architecture)

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

6

6

Model 1 Architecture (Page-centric)

Request

1

JSPpages

Java Bean

Response

4

2

3

BR

OW

SE

R

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.

7

7

Page-centric Architecture

memu.jsp catalog.jsp checkout.jsp

dataBase

page–centric catalog application

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.

8

8

Model 2(Servlet-Centric

Architecture)

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

9

9

Model 2 Architecture (Servlet-centric)

Request

1

(Controller)Servlet

(View)JSPResponse

5

3

4

BR

OW

SE

R

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.

10

10

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.

11

11

What is & Why JSF?What is & Why JSF?

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

12

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.

12

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.

13

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.

13

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: Sun Java Studio Creator– You can still create JSF application by writing JSP

pages yourself

14

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.

14

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

15

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.

15

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

16

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.

16

Why JSF? ? 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)

17

17

JSF Design GoalsJSF Design Goals

18

18

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? Scalable

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.

19

19

How the JSF Specification Fits In

JSF App

Servlets (2.3)

JSP (1.2) JSF API

JSF Tags

JSF App

This 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.

20

20

Quick Overview on Quick Overview on JSF Architecture,JSF Architecture,

Concept, & FeaturesConcept, & 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.

21

21

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.

22

22

JSF Architecture

HTML RenderKit

AppBackend

DesktopBrowser

Phone

Frontctrl

JSF 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.

23

23

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.

24

24

Key JSF Concepts? UIComponent

– Render-independent characteristics– Base class with standard behaviors

? Standard UIComponent Subclasses:– UICommand, UIForm, UIGraphic, UIInput,

UIOutput, UIPanel, UISelectBoolean, UISelectMany, UISelectOne

? 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.

25

25

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

26

26

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

27

27

Relationship to Other JSRs? JSF 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 is not part of J2EE 1.4 standard yet– Will be considered for J2EE 5.0– It is included in J2EE 1.4 SDK, however

28

28

Developer RolesDeveloper Roles

29

29

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.

30

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.

30

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” IDE like Sun Java Studio

Creator? Component Writer – Creates reusable

components, renderers, and libraries– Components – Render-independent properties– Renderers – Render-dependent properties

31

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.

31

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

32

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

32

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: Sun Java Studio Creator

? JSF Implementor – Provides runtime environment to execute JSF webapps

– J2EE SDK 1.4

33

33

Important Built-inImportant Built-inClassesClasses

Having a good grasp on UI component model of JSF is absolutely critical because after all JSF is all about UI component model.

34

34

UIViewRoot? UIViewRoot is a UIComponent that

represents the root of the UIComponent tree.

? Serves as the root of the component tree, and as a place to hang per-view PhaseListeners

.

35

35

UIViewRoot? UIViewRoot is a UIComponent that

represents the root of the UIComponent tree.

? Serves as the root of the component tree, and as a place to hang per-view PhaseListeners

.

36

36

FacesContext? Contains all of the per-request state

information related to the processing of a single JavaServer Faces request, and the rendering of the corresponding response.

? It is passed to, and potentially modified by, each phase of the request processing lifecycle

.

37

37

PhaseListener? An interface implemented by objects that

wish to be notified at the beginning and ending of processing for each standard phase of the request processing lifecycle

? You can provide your own implementation of PhaseListener and plug it into the application for custom request handling

– Ajax request handling? Before and after each phase handling

– “around” semantics

.

38

38

Application Class? Represents a per-web-application singleton

object ? Maintains application wide objects

– set of supported locales– converters– validators

? Serves as a factory for creating components, converters, and validators

public abstract UIComponent createComponent(String componentType) throws FacesException

.

39

39

ApplicationConfiguration

40

40

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 <faces-config> tag must enclose all of the

other declarations<faces-config> ....</faces-config>

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.

41

41

faces-config.xml of guessNumber<?xml version="1.0"?>



<!DOCTYPE faces-config PUBLIC "-//Sun Microsystems, Inc.//DTD JavaServer Faces Config 1.0//EN" "http://java.sun.com/dtd/web-facesconfig_1_0.dtd">

<faces-config>

<application> <locale-config> <default-locale>en</default-locale> <supported-locale>de</supported-locale> <supported-locale>fr</supported-locale> <supported-locale>es</supported-locale> </locale-config> </application>

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

42

42

faces-config.xml of guessNumber <navigation-rule> ... <from-view-id>/greeting.jsp</from-view-id> ... </navigation-rule>

<navigation-rule> ... <from-view-id>/response.jsp</from-view-id> ... </navigation-rule>

<managed-bean> ... <managed-bean-name>UserNumberBean</managed-bean-name> ... <managed-bean>

</faces-config>

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

43

43

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 <JWSDP_HOME>/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.

44

44

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.

45

45

Backing Bean(Model Object)Management

46

46

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.

47

47

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.

48

48

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.

49

49

Example: Binding Component Value to Backing Bean in greeting.jsp <h:inputText id="userNo" value="#{UserNumberBean.userNumber}" validator="#{UserNumberBean.validate}"/>

? 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:

<h:inputText id="userNo" value="#{UserNumberBean.userNumber}" validator="#{UserNumberBean.validate}" />

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

50

50

UserNumberBean in faces-config.xml<managed-bean> <description> The "backing file" bean that backs up the guessNumber webapp </description> <managed-bean-name>UserNumberBean</managed-bean-name> <managed-bean-class>guessNumber.UserNumberBean</managed-bean-class> <managed-bean-scope>session</managed-bean-scope> <managed-property> <property-name>minimum</property-name> <property-class>int</property-class> <value>0</value> </managed-property> <managed-property> <property-name>maximum</property-name> <property-class>int</property-class> <value>10</value> </managed-property></managed-bean>

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

51

51

Page Navigation

52

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.

52

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

53

53

Navigation Rule 1 for guessNumber Example (V1) <navigation-rule> <description> The decision rule used by the NavigationHandler to determine which view must be displayed after the current view, greeting.jsp is processed. </description> <from-view-id>/greeting.jsp</from-view-id> <navigation-case> <description> 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". </description> <from-outcome>success</from-outcome> <to-view-id>/response.jsp</to-view-id> </navigation-case> </navigation-rule>

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).

54

54

Navigation Rule 2 for guessNumber Example (V1) <navigation-rule> <description> The decision rules used by the NavigationHandler to determine which view must be displayed after the current view, response.jsp is processed. </description> <from-view-id>/response.jsp</from-view-id> <navigation-case> <description> 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". </description> <from-outcome>success</from-outcome> <to-view-id>/greeting.jsp</to-view-id> </navigation-case> </navigation-rule>


55

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


55

Navigation Rule? <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 <navigation-case> elements

? <navigation-case>– defines the page to open next (defined by to-tree-

id) based on a logical outcome (defined by from-outcome)

56

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

<h:command_button id="submit" action="success" label="Submit" />

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.

56

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 (#{<BackingBean>.<Method>})<h:commandButton id="submit" action="success" label="Submit" /> <h:commandButton action="#{carstore.buyCurrentCar}"

value="#{bundle.buy}" />

57

57

Passion!

javaserver faces (jsf) overview -...

Documents