Faces Configuration File
The faces-config.xml is, by convention, the main configuration file in a JSF application. It is placed in the WEB-INF
folder of an application. As its suffix suggests, it is an XML file. <faces-config> defines the root element of the
configuration file.
faces-config.xml
<?xml version="1.0" encoding="UTF-8"?>
<faces-config xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.
com/xml/ns/javaee/web-facesconfig_2_0.xsd"
version="2.0">
<navigation-rule>
<description>Success and failure nav from login page</description>
<from-view-id>/login.xhtml</from-view-id>
<navigation-case>
<from-outcome>authenticated</from-outcome>
<to-view-id>/welcome.xhtml</to-view-id>
</navigation-case>
</navigation-rule>
</faces-config>
Navigational rules are defined in a <navigation-rule> child element of <faces-config>. Each rule is defined for a
particular starting point or page. The <from-view-id> child element of a navigation rule specifies that starting point.
In other words, the <from-view-id> specifies navigational routes from the indicated page. Routes are called
navigational cases. In this example, there is only one navigation rule containing one navigation case, but there could
be any number or rules containing any number of cases.
Each navigational case includes a <from-outcome> and <to-view-id> elements. The <from-outcome> element lists
an action string that might be returned from an action method called from the from-view page. The navigation
handler looks up the returned string from action method and matches it to one of the from-outcome elements in all
the navigational cases. When found, the <to-view-id> view is loaded by JSF and displayed back to the user. In the
example, if the authenticate action method returns “authenticated” then the result is to load and display the welcome.
xhtml.
.
Action methods may also return null as in the example authenticate method. Returning null is an indication that the
same view should be redisplayed. In this example, when the person is not authorized into the site, the login.xhtml
page is redisplayed with a message indicating no access. Note the #{loginBean.error} EL on the page to display the
error message when this occurs.
Manged beans, such as LoginBean, are defined by Java annotations in JSF 2.0. However, prior to JSF 2.0 (JSF 1.2
and earlier) managed beans were define in <managed-bean> child elements of <faces-config>. If you prefer, XML
configuration in the Faces config file can be used in place of annotations as shown below.
The managed-bean element from the faces-config.xml that associates “loginBean” to the LoginBean. This XML
could be used in place of annotations in the LoginBean class.
<managed-bean>
<managed-bean-name>loginBean</managed-bean-name>
<managed-bean-class>
com.intertech.domain.LoginBean
</managed-bean-class>
<managed-bean-scope>session</managed-bean-scope>
<managed-property>
<property-name>name</property-name>
<value>Your name here</value>
</managed-property>
</managed-bean>
As a minimum, a <managed-bean> element must define the name, class and scope of a managed bean. The name
given to the managed bean (in this case “loginBean”) allows the bean to be referenced in the Unified EL in Facelets
and JSP views. The scope element takes the place of the @SessionScoped annotation and defines the life of a
managed bean. Choices for scope include request, session, application or none. Additionally and optionally, as
shown in the example, property values for the managed bean can be set through the faces-config.xml. The <managed-
property> element defines initialization values for any of the managed bean’s properties like name on LoginBean.
The <managed-property> element takes the place of the @ManagedProperty annotation.
OK, so now you are done! While the application is not large (or complete), you have an understanding of JSF
basics.
• How JSF views are specified in Facelets.
• How Facelet views are encoded and decoded.
• How managed beans are associated to views via Unified EL.
• How data is moved between the managed beans and the views.
• How JSF applications are configured.
• How navigational rules defined the navigation between JSF views.
In the coming chapters, more details and additional capability will be added to this understanding.
• This includes, but is not limited to:
• More information on Facelets, Facelet tags and the underlying UI components.
• JSF’s event handling.
• JSPs as alternates to Facelets.
• Data validation and conversion.
• Internationalization/localization support.
• Additional navigation configuration.
The faces-config.xml is, by convention, the main configuration file in a JSF application. It is placed in the WEB-INF
folder of an application. As its suffix suggests, it is an XML file. <faces-config> defines the root element of the
configuration file.
faces-config.xml
<?xml version="1.0" encoding="UTF-8"?>
<faces-config xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.
com/xml/ns/javaee/web-facesconfig_2_0.xsd"
version="2.0">
<navigation-rule>
<description>Success and failure nav from login page</description>
<from-view-id>/login.xhtml</from-view-id>
<navigation-case>
<from-outcome>authenticated</from-outcome>
<to-view-id>/welcome.xhtml</to-view-id>
</navigation-case>
</navigation-rule>
</faces-config>
Navigational rules are defined in a <navigation-rule> child element of <faces-config>. Each rule is defined for a
particular starting point or page. The <from-view-id> child element of a navigation rule specifies that starting point.
In other words, the <from-view-id> specifies navigational routes from the indicated page. Routes are called
navigational cases. In this example, there is only one navigation rule containing one navigation case, but there could
be any number or rules containing any number of cases.
Each navigational case includes a <from-outcome> and <to-view-id> elements. The <from-outcome> element lists
an action string that might be returned from an action method called from the from-view page. The navigation
handler looks up the returned string from action method and matches it to one of the from-outcome elements in all
the navigational cases. When found, the <to-view-id> view is loaded by JSF and displayed back to the user. In the
example, if the authenticate action method returns “authenticated” then the result is to load and display the welcome.
xhtml.
.
Action methods may also return null as in the example authenticate method. Returning null is an indication that the
same view should be redisplayed. In this example, when the person is not authorized into the site, the login.xhtml
page is redisplayed with a message indicating no access. Note the #{loginBean.error} EL on the page to display the
error message when this occurs.
Manged beans, such as LoginBean, are defined by Java annotations in JSF 2.0. However, prior to JSF 2.0 (JSF 1.2
and earlier) managed beans were define in <managed-bean> child elements of <faces-config>. If you prefer, XML
configuration in the Faces config file can be used in place of annotations as shown below.
The managed-bean element from the faces-config.xml that associates “loginBean” to the LoginBean. This XML
could be used in place of annotations in the LoginBean class.
<managed-bean>
<managed-bean-name>loginBean</managed-bean-name>
<managed-bean-class>
com.intertech.domain.LoginBean
</managed-bean-class>
<managed-bean-scope>session</managed-bean-scope>
<managed-property>
<property-name>name</property-name>
<value>Your name here</value>
</managed-property>
</managed-bean>
As a minimum, a <managed-bean> element must define the name, class and scope of a managed bean. The name
given to the managed bean (in this case “loginBean”) allows the bean to be referenced in the Unified EL in Facelets
and JSP views. The scope element takes the place of the @SessionScoped annotation and defines the life of a
managed bean. Choices for scope include request, session, application or none. Additionally and optionally, as
shown in the example, property values for the managed bean can be set through the faces-config.xml. The <managed-
property> element defines initialization values for any of the managed bean’s properties like name on LoginBean.
The <managed-property> element takes the place of the @ManagedProperty annotation.
OK, so now you are done! While the application is not large (or complete), you have an understanding of JSF
basics.
• How JSF views are specified in Facelets.
• How Facelet views are encoded and decoded.
• How managed beans are associated to views via Unified EL.
• How data is moved between the managed beans and the views.
• How JSF applications are configured.
• How navigational rules defined the navigation between JSF views.
In the coming chapters, more details and additional capability will be added to this understanding.
• This includes, but is not limited to:
• More information on Facelets, Facelet tags and the underlying UI components.
• JSF’s event handling.
• JSPs as alternates to Facelets.
• Data validation and conversion.
• Internationalization/localization support.
• Additional navigation configuration.
Faces Configuration File
Table of Contents
Copyright (c) 2008. Intertech, Inc. All Rights Reserved. This information is to be used exclusively as an
online learning aid. Any attempts to copy, reproduce, or use for training is strictly prohibited.
online learning aid. Any attempts to copy, reproduce, or use for training is strictly prohibited.
 |
 |
 |
 |
 |
 |
 |
 |
 |
Courseware
Training Resources
Tutorials
Services