The process of building and deploying simple JavaServer Faces applications is described in earlier chapters of this tutorial, including Chapter 6, "Getting Started with Web Applications," Chapter 8, "Introduction to Facelets," Chapter 13, "Using Ajax with JavaServer Faces Technology," and Chapter 14, "Composite Components: Advanced Topics and an Example." When you create large and complex applications, however, various additional configuration tasks are required. These tasks include the following:
Registering managed beans with the application so that all parts of the application have access to them
Configuring managed beans and model beans so that they are instantiated with the proper values when a page makes reference to them
Defining navigation rules for each of the pages in the application so that the application has a smooth page flow, if nondefault navigation is needed
Packaging the application to include all the pages, resources, and other files so that the application can be deployed on any compliant container
The following topics are addressed here:
JavaServer Faces support for bean annotations is introduced in Chapter 7, "JavaServer Faces Technology". Bean annotations can be used for configuring JavaServer Faces applications.
The @Named
(javax.inject.Named
) annotation in a class, along with a scope annotation, automatically registers that class as a resource with the JavaServer Faces implementation. A bean that uses these annotations is a CDI managed bean.
The following shows the use of the @Named
and @SessionScoped
annotations in a class:
@Named("cart") @SessionScoped public class ShoppingCart ... { ... }
The above code snippet shows a bean that is managed by the JavaServer Faces implementation and is available for the length of the session.
You can annotate beans with any of the scopes listed in the next section, Using Managed Bean Scopes.
All classes will be scanned for annotations at startup unless the faces-config
element in the faces-config.xml
file has the metadata-complete
attribute set to true
.
Annotations are also available for other artifacts, such as components, converters, validators, and renderers, to be used in place of application configuration resource file entries. These are discussed, along with registration of custom listeners, custom validators, and custom converters, in Chapter 15, "Creating Custom UI Components and Other Custom Objects".
You can use annotations to define the scope in which the bean will be stored. You can specify one of the following scopes for a bean class.
Application (javax.enterprise.context.ApplicationScoped
): Application scope persists across all users' interactions with a web application.
Session (javax.enterprise.context.SessionScoped
): Session scope persists across multiple HTTP requests in a web application.
Flow (javax.faces.flows.FlowScoped
): Flow scope persists during a user's interaction with a specific flow of a web application. See Using Faces Flows for more information.
Request (javax.enterprise.context.RequestScoped
): Request scope persists during a single HTTP request in a web application.
Dependent (javax.enterprise.context.Dependent
): Indicates that the bean depends on some other bean.
You may want to use @Dependent
when a managed bean references another managed bean. The second bean should not be in a scope (@Dependent
) if it is supposed to be created only when it is referenced. If you define a bean as @Dependent
, the bean is instantiated anew each time it is referenced, so it does not get saved in any scope.
If your managed bean is referenced by the binding
attribute of a component tag, you should define the bean with a request scope. If you placed the bean in session or application scope instead, the bean would need to take precautions to ensure thread safety, because javax.faces.component.UIComponent
instances each depend on running inside of a single thread.
If you are configuring a bean that allows attributes to be associated with the view, you can use the view scope. The attributes persist until the user has navigated to the next view.
JavaServer Faces technology provides a portable configuration format (as an XML document) for configuring application resources. One or more XML documents, called application configuration resource files, may use this format to register and configure objects and resources and to define navigation rules for applications. An application configuration resource file is usually named faces-config.xml
.
You need an application configuration resource file in the following cases:
To specify configuration elements for your application that are not available through managed bean annotations, such as localized messages and navigation rules
To override managed bean annotations when the application is deployed
The application configuration resource file must be valid against the XML schema located at http://xmlns.jcp.org/xml/ns/javaee/web-facesconfig_2_2.xsd
.
In addition, each file must include the following information, in the following order:
The XML version number, usually with an encoding
attribute:
<?xml version="1.0" encoding='UTF-8'?>
A faces-config
tag enclosing all the other declarations:
<faces-config version="2.2" xmlns="http://xmlns.jcp.org/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-facesconfig_2_2.xsd"> ... </faces-config>
You can have more than one application configuration resource file for an application. The JavaServer Faces implementation finds the configuration file or files by looking for the following.
A resource named /META-INF/faces-config.xml
in any of the JAR files in the web application's /WEB-INF/lib/
directory and in parent class loaders. 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. In addition, any file with a name that ends in faces-config.xml
is also considered a configuration resource and is loaded as such.
A context initialization parameter, javax.faces.application.CONFIG_FILES
, in your web deployment descriptor file that specifies one or more (comma-delimited) paths to multiple configuration files for your web application. This method is most often used for enterprise-scale applications that delegate to separate groups the responsibility for maintaining the file for each portion of a big application.
A resource named faces-config.xml
in the /WEB-INF/
directory of your application. Simple web applications make their configuration files available in this way.
To access the resources registered with the application, an application developer can use an instance of the javax.faces.application.Application
class, which is automatically created for each application. The Application
instance 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 provided in the application configuration resource file.
JavaServer Faces managed beans (either specified in the faces-config.xml
file or annotated with javax.faces.bean.ManagedBean
) are lazily instantiated. That is, that they are instantiated when a request is made from the application.
To force an application-scoped bean to be instantiated and placed in the application scope as soon as the application is started and before any request is made, the eager
attribute of the managed bean should be set to true
, as shown in the following examples.
The faces-config.xml
file declaration is as follows:
<managed-bean eager="true">
The annotation is as follows:
@ManagedBean(eager=true) @ApplicationScoped
Because JavaServer Faces technology allows the use of multiple application configuration resource files stored in different locations, the order in which they are loaded by the implementation becomes important in certain situations (for example, when using application-level objects). This order can be defined through an ordering
element and its subelements in the application configuration resource file itself. The ordering of application configuration resource files can be absolute or relative.
Absolute ordering is defined by an absolute-ordering
element in the file. With absolute ordering, the user specifies the order in which application configuration resource files will be loaded. The following example shows an entry for absolute ordering.
File my-faces-config.xml
contains the following elements:
<faces-config> <name>myJSF</name> <absolute-ordering> <name>A</name> <name>B</name> <name>C</name> </absolute-ordering> </faces-config>
In this example, A, B, and C are different application configuration resource files and are to be loaded in the listed order.
If there is an absolute-ordering
element in the file, only the files listed by the subelement name
are processed. To process any other application configuration resource files, an others
subelement is required. In the absence of the others
subelement, all other unlisted files will be ignored at load time.
Relative ordering is defined by an ordering
element and its subelements before
and after
. With relative ordering, the order in which application configuration resource files will be loaded is calculated by considering ordering entries from the different files. The following example shows some of these considerations. In the following example, config-A
, config-B
, and config-C
are different application configuration resource files.
File config-A
contains the following elements:
<faces-config> <name>config-A</name> <ordering> <before> <name>config-B</name> </before> </ordering> </faces-config>
File config-B
(not shown here) does not contain any ordering
elements.
File config-C
contains the following elements:
<faces-config> <name>config-C</name> <ordering> <after> <name>config-B</name> </after> </ordering> </faces-config>
Based on the before
subelement entry, file config-A
will be loaded before the config-B
file. Based on the after
subelement entry, file config-C
will be loaded after the config-B
file.
In addition, a subelement others
can also be nested within the before
and after
subelements. If the others
element is present, the specified file may receive highest or lowest preference among both listed and unlisted configuration files.
If an ordering
element is not present in an application configuration file, then that file will be loaded after all the files that contain ordering
elements.
The Faces Flows feature of JavaServer Faces technology allows you to create a set of pages with a scope, FlowScoped
, that is greater than request scope but less than session scope. For example, you might want to create a series of pages for the checkout process in an online store. You could create a set of self-contained pages that could be transferred from one store to another as needed.
Faces Flows are somewhat analogous to subroutines in procedural programming, in the following ways.
Like a subroutine, a flow has a well defined entry point, list of parameters, and return value. However, unlike a subroutine, a flow can return multiple values.
Like a subroutine, a flow has a scope, allowing information to be available only during the invocation of the flow. Such information is not available outside the scope of the flow and does not consume any resources once the flow returns.
Like a subroutine, a flow may call other flows before returning. The invocation of flows is maintained in a call stack: a new flow causes a push onto the stack, and a return causes a pop.
An application can have any number of flows. Each flow includes a set of pages and, usually, one or more managed beans scoped to that flow. Each flow has a starting point, called a start node, and an exit point, called a return node.
The data in a flow is scoped to that flow alone, but you can pass data from one flow to another by specifying parameters and calling the other flow.
Flows can be nested, so that if you call one flow from another and then exit the second flow, you return to the calling flow rather than to the second flow's return node.
You can configure a flow programmatically, by creating a class annotated @FlowDefinition
, or you can configure a flow by using a configuration file. The configuration file can be limited to one flow, or you can use the faces-config.xml
file to put all the flows in one place, if you have many flows in an application. The programmatic configuration places the code closer to the rest of the flow code and enables you to modularize the flows.
Figure 16-1 shows two flows and illustrates how they interact.
Figure 16-1 Two Faces Flows and Their Interactions
In this figure, Flow A has a start node named flow-a
and two additional pages, next_a1
and next_a2
. From next_a2
, a user can either exit the flow using the defined return node, taskFlowReturn1
, or call Flow B, passing two parameters. Flow A also defines two inbound parameters that it can accept from Flow B. Flow B is identical to Flow A except for the names of the flow and files. Each flow also has an associated managed bean; the beans are Flow_a_Bean
and Flow_b_Bean
.
Typically, you package flows in a web application using a directory structure that modularizes the flows. In the src/main/webapp
directory of a Maven project, for example, you would place the Facelets files that are outside the flow at the top level as usual. Then the webapp
files for each flow would be in a separate directory, and the Java files would be under src/main/java
. For example, the files for the application shown in Figure 16-1 might look like this:
src/main/webapp/ index.xhtml return.xhtml WEB_INF/ beans.xml web.xml flow-a/ flow-a.xhtml next_a1.xhtml next_a2.xhtml flow-b/ flow-b-flow.xml next_b1.xhtml next_b2.xhtml src/main/java/javaeetutorial/flowexample FlowA.java Flow_a_Bean.java Flow_b_Bean.java
In this example, flow-a
is defined programmatically in FlowA.java
, while flow-b
is defined by the configuration file flow-b-flow.xml
.
The simple-flow
example application demonstrates the most basic building blocks of a Faces Flows application and illustrates some of the conventions that make it easy to get started with iterative development using flows. You may want to start with a simple example like this one and build upon it.
This example provides an implicit flow definition by including an empty configuration file. A configuration file that has content, or a class annotated @FlowDefinition
, provides an explicit flow definition.
The source code for this application is in the tut-install/examples/web/jsf/simple-flow/
directory.
The file layout of the simple-flow
example looks like this:
src/main/webapp index.xhtml simple-flow-return.xhtml WEB_INF/ web.xml simple-flow simple-flow-flow.xml simple-flow.xhtml simple-flow-page2.xhtml
The simple-flow
example has an empty configuration file, which is by convention named flow-name-flow.xml
. The flow does not require any configuration for the following reasons.
The flow does not call another flow, nor does it pass parameters to another flow.
The flow uses default names for the first page of the flow, flow-name.xhtml
, and the return page, flow-name-return.xhtml
.
This example has only four Facelets pages.
index.xhtml
, the start page, which contains almost nothing but a button that navigates to the first page of the flow:

<h:commandButton value="Enter Flow" action="simple-flow"/>

simple-flow.xhtml
and simple-flow-page2.xhtml
, the two pages of the flow itself. In the absence of an explicit flow definition, the page whose name is the same as the name of the flow is assumed to be the start node of the flow. In this case, the flow is named simple-flow
, so the page named simple-flow.xhtml
is assumed to be the start node of the flow. The start node is the node navigated to upon entry into the flow. It can be thought of as the home page of the flow.
The simple-flow.xhtml
page asks you to enter a flow-scoped value and provides a button that navigates to the next page of the flow:

Value: <h:inputText id="input" value="#{flowScope.value}" />

<h:commandButton value="Next" action="simple-flow-page2" />

The second page, which can have any name, displays the flow-scoped value and provides a button that navigates to the return page:

Value: #{flowScope.value}

<h:commandButton value="Return" action="simple-flow-return" />

simple-flow-return.xhtml
, the return page. The return page, which by convention is named flow-name-return.xhtml
, must be located outside of the flow. This page displays the flow-scoped value, to show that it has no value outside of the flow, and provides a link that navigates to the index.xhtml
page:

Value (should be empty): "<h:outputText id="output" value="#{flowScope.value}" />"

<h:link outcome="index" value="Back to Start" />

The Facelets pages use only flow-scoped data, so the example does not need a managed bean.
Make sure that GlassFish Server has been started (see Starting and Stopping GlassFish Server).
From the File menu, choose Open Project.
In the Open Project dialog box, navigate to:
tut-install/examples/web/jsf
Select the simple-flow
folder.
Click Open Project.
In the Projects tab, right-click the simple-flow
project and select Build.
This command builds and packages the application into a WAR file, simple-flow.war
, that is located in the target
directory. It then deploys the application to the server.
Make sure that GlassFish Server has been started (see Starting and Stopping GlassFish Server).
In a terminal window, go to:
tut-install/examples/web/jsf/simple-flow/
Enter the following command:
mvn install
This command builds and packages the application into a WAR file, simple-flow.war
, that is located in the target
directory. It then deploys the application to the server.
Enter the following URL in your web browser:
http://localhost:8080/simple-flow
On the index.xhtml
page, click Enter Flow.
On the first page of the flow, enter any string in the Value field, then click Next.
On the second page of the flow, you can see the value you entered. Click Return.
On the return page, an empty pair of quotation marks encloses the inaccessible value. Click Back to Start to return to the index.xhtml
page.
The checkout-module
example application is considerably more complex than simple-flow
. It shows how you might use the Faces Flows feature to implement a checkout module for an online store.
Like the hypothetical example in Figure 16-1, the example application contains two flows, each of which can call the other. Both flows have explicit flow definitions. One flow, checkoutFlow
, is specified programmatically. The other flow, joinFlow
, is specified in a configuration file.
The source code for this application is in the tut-install/examples/web/jsf/checkout-module/
directory.
For the checkout-module
application, the directory structure is as follows (there is also a src/main/webapp/resources
directory with a stylesheet and an image):
src/main/webapp/ index.xhtml exithome.xhtml WEB_INF/ beans.xml web.xml checkoutFlow/ checkoutFlow.xhtml checkoutFlow2.xhtml checkoutFlow3.xhtml checkoutFlow4.xhtml joinFlow/ joinFlow-flow.xml joinFlow.xhtml joinFlow2.xhtml src/main/java/javaeetutorial/checkoutmodule CheckoutBean.java CheckoutFlow.java CheckoutFlowBean.java JoinFlowBean.java
For the example, index.xhtml
is the beginning page for the application as well as the return node for the checkout flow. The exithome.xhtml
page is the return node for the join flow.
The configuration file joinFlow-flow.xml
defines the join flow, and the source file CheckoutFlow.java
defines the checkout flow.
The checkout flow contains four Facelets pages, whereas the join flow contains two.
The managed beans scoped to each flow are CheckoutFlowBean.java
and JoinFlowBean.java
, whereas CheckoutBean.java
is the backing bean for the index.html
page.
The starting page for the example, index.xhtml
, summarizes the contents of a hypothetical shopping cart. It allows the user to click either of two buttons to enter one of the two flows:

<h:commandButton value="Check Out" action="checkoutFlow"/>
 ...
<h:commandButton value="Join" action="joinFlow"/>

This page is also the return node for the checkout flow.
The Facelets page exithome.xhtml
is the return node for the join flow. This page has a button that allows you to return to the index.xhtml
page.
The four Facelets pages within the checkout flow, starting with checkoutFlow.xhtml
and ending with checkoutFlow4.xhtml
, allow you to proceed to the next page or, in some cases, to return from the flow. The checkoutFlow.xhtml
page allows you to access parameters passed from the join flow through the flow scope. These appear as empty quotation marks if you have not called the checkout flow from the join flow.

If you called this flow from the Join flow, you can see these parameters: "<h:outputText value="#{flowScope.param1Value}"/>" and "<h:outputText value="#{flowScope.param2Value}"/>"

Only checkoutFlow2.xhtml
has a button to return to the previous page, but moving between pages is generally permitted within flows. Here are the buttons for checkoutFlow2.xhtml
:

<h:commandButton value="Continue" action="checkoutFlow3"/>

<h:commandButton value="Go Back" action="checkoutFlow"/>

<h:commandButton value="Exit Flow" action="returnFromCheckoutFlow"/>

The action returnFromCheckoutFlow
is defined in the configuration source code file, CheckoutFlow.java
.
The final page of the checkout flow, checkoutFlow4.xhtml
, contains a button that calls the join flow:

<h:commandButton value="Join" action="calljoin"/>

<h:commandButton value="Exit Flow" action="returnFromCheckoutFlow"/>

The calljoin
action is also defined in the configuration source code file, CheckoutFlow.java
. This action enters the join flow, passing two parameters from the checkout flow.
The two pages in the join flow, joinFlow.xhtml
and joinFlow2.xhtml
, are similar to those in the checkout flow. The second page has a button to call the checkout flow as well as one to return from the join flow:

<h:commandButton value="Check Out" action="callcheckoutFlow"/>

<h:commandButton value="Exit Flow" action="returnFromJoinFlow"/>

For this flow, the actions callcheckoutFlow
and returnFromJoinFlow
are defined in the configuration file joinFlow-flow.xml
.
If you use an application configuration resource file to configure a flow, it must be named flowName-flow.xml
. In this example, the join flow uses a configuration file named joinFlow-flow.xml
. The file is a faces-config
file that specifies a flow-definition
element. This element must define the flow name using the id
attribute. Under the flow-definition
element, there must be a flow-return
element that specifies the return point for the flow. Any inbound parameters are specified with inbound-parameter
elements. If the flow calls another flow, the call-flow
element must use the flow-reference element to name the called flow and may use the outbound-parameter
element to specify any outbound parameters.
The configuration file for the join flow looks like this:
<faces-config version="2.2" xmlns="http://xmlns.jcp.org/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee \ http://xmlns.jcp.org/xml/ns/javaee/web-facesconfig_2_2.xsd"> <flow-definition id="joinFlow"> <flow-return id="returnFromJoinFlow"> <from-outcome>#{joinFlowBean.returnValue}</from-outcome> </flow-return> <inbound-parameter> <name>param1FromCheckoutFlow</name> <value>#{flowScope.param1Value}</value> </inbound-parameter> <inbound-parameter> <name>param2FromCheckoutFlow</name> <value>#{flowScope.param2Value}</value> </inbound-parameter> <flow-call id="callcheckoutFlow"> <flow-reference> <flow-id>checkoutFlow</flow-id> </flow-reference> <outbound-parameter> <name>param1FromJoinFlow</name> <value>param1 joinFlow value</value> </outbound-parameter> <outbound-parameter> <name>param2FromJoinFlow</name> <value>param2 joinFlow value</value> </outbound-parameter> </flow-call> </flow-definition> </faces-config>
The id
attribute of the flow-definition
element defines the name of the flow as joinFlow
. The value of the id
attribute of the flow-return
element identifies the name of the return node, and its value is defined in the from-outcome
element as the returnValue
property of the flow-scoped managed bean for the join flow, JoinFlowBean
.
The names and values of the inbound parameters are retrieved from the flow scope in order (flowScope.param1Value
, flowScope.param2Value
), based on the way they were defined in the checkout flow configuration.
The flow-call
element defines how the join flow calls the checkout flow. The id
attribute of the element, callcheckoutFlow
, defines the action of calling the flow. Within the flow-call
element, the flow-reference
element defines the actual name of the flow to call, checkoutFlow
. The outbound-parameter
elements define the parameters to be passed when checkoutFlow
is called. Here they are just arbitrary strings.
If you use a Java class to configure a flow, it must have the name of the flow. The class for the checkout flow is called CheckoutFlow.java
.
import java.io.Serializable; import javax.enterprise.inject.Produces; import javax.faces.flow.Flow; import javax.faces.flow.builder.FlowBuilder; import javax.faces.flow.builder.FlowBuilderParameter; import javax.faces.flow.builder.FlowDefinition; class CheckoutFlow implements Serializable { private static final long serialVersionUID = 1L; @Produces @FlowDefinition public Flow defineFlow(@FlowBuilderParameter FlowBuilder flowBuilder) { String flowId = "checkoutFlow"; flowBuilder.id("", flowId); flowBuilder.viewNode(flowId, "/" + flowId + "/" + flowId + ".xhtml"). markAsStartNode(); flowBuilder.returnNode("returnFromCheckoutFlow"). fromOutcome("#{checkoutFlowBean.returnValue}"); flowBuilder.inboundParameter("param1FromJoinFlow", "#{flowScope.param1Value}"); flowBuilder.inboundParameter("param2FromJoinFlow", "#{flowScope.param2Value}"); flowBuilder.flowCallNode("calljoin").flowReference("", "joinFlow"). outboundParameter("param1FromCheckoutFlow", "#{checkoutFlowBean.name}"). outboundParameter("param2FromCheckoutFlow", "#{checkoutFlowBean.city}"); return flowBuilder.getFlow(); } }
The class performs actions that are almost identical to those performed by the configuration file joinFlow-flow.xml
. It contains a single method, defineFlow
, as a producer method with the @FlowDefinition
qualifier that returns a javax.faces.flow.Flow
class. The defineFlow
method takes one parameter, a FlowBuilder
with the qualifier @FlowBuilderParameter
, which is passed in from the JavaServer Faces implementation. The method then calls methods from the javax.faces.flow.Builder.FlowBuilder
class to configure the flow.
First, the method defines the flow id
as checkoutFlow
. Then, it explicitly defines the start node for the flow. By default, this is the name of the flow with an .xhtml
suffix.
The method then defines the return node similarly to the way the configuration file does. The returnNode
method sets the name of the return node as returnFromCheckoutFlow
, and the chained fromOutcome
method specifies its value as the returnValue
property of the flow-scoped managed bean for the checkout flow, CheckoutFlowBean
.
The inboundParameter
method sets the names and values of the inbound parameters from the join flow, which are retrieved from the flow scope in order (flowScope.param1Value
, flowScope.param2Value
), based on the way they were defined in the join flow configuration.
The flowCallNode
method defines how the checkout flow calls the join flow. The argument, calljoin
, specifies the action of calling the flow. The chained flowReference
method defines the actual name of the flow to call, joinFlow
, then calls outboundParameter
methods to define the parameters to be passed when joinFlow
is called. Here they are values from the CheckoutFlowBean
managed bean.
Finally, the defineFlow
method calls the getFlow
method and returns the result.
Each of the two flows has a managed bean that defines properties for the pages within the flow. For example, the CheckoutFlowBean
defines properties whose values are entered by the user on both the checkoutFlow.xhtml
page and the checkoutFlow3.xhtml
page.
Each managed bean has a getReturnValue
method that sets the value of the return node. For the CheckoutFlowBean
, the return node is the index.xhtml
page, specified using implicit navigation:
public String getReturnValue() { return "index"; }
For the JoinFlowBean
, the return node is the exithome.xhtml
page.
Make sure that GlassFish Server has been started (see Starting and Stopping GlassFish Server).
From the File menu, choose Open Project.
In the Open Project dialog box, navigate to:
tut-install/examples/web/jsf
Select the checkout-module
folder.
Click Open Project.
In the Projects tab, right-click the checkout-module
project and select Build.
This command builds and packages the application into a WAR file, checkout-module.war
, that is located in the target
directory. It then deploys the application to the server.
Make sure that GlassFish Server has been started (see Starting and Stopping GlassFish Server).
In a terminal window, go to:
tut-install/examples/web/jsf/checkout-module/
Enter the following command:
mvn install
This command builds and packages the application into a WAR file, checkout-module.war
, that is located in the target
directory. It then deploys the application to the server.
Enter the following URL in your web browser:
http://localhost:8080/checkout-module
The index.xhtml
page presents hypothetical results of the shopping expedition. Click either Check Out or Join to enter one of the two flows.
Follow the flow, providing input as needed and choosing whether to continue, go back, or exit the flow.
In the checkout flow, only one of the input fields is validated (the credit card field expects 16 digits), so you can enter any values you like. The join flow does not require you to check any boxes in its checkbox menus.
On the last page of a flow, select the option to enter the other flow. This allows you to view the inbound parameters from the previous flow.
Because flows are nested, if you click Exit Flow from a called flow, you will return to the first page of the calling flow. (You may see a warning, which you can ignore.) Click Exit Flow on that page to go to the specified return node.
When a page references a managed bean for the first time, the JavaServer Faces implementation initializes it either based on a @Named
annotation and scope annotation in the bean class or according to its configuration in the application configuration resource file. For information on using annotations to initialize beans, see Using Annotations to Configure Managed Beans.
You can use either annotations or the application configuration resource file to instantiate managed beans that are used in a JavaServer Faces application and to store them in scope. The managed bean creation facility is configured in the application configuration resource file using managed-bean
XML elements to define each bean. This file is processed at application startup time. For information on using this facility, see Using the managed-bean Element.
Managed beans created in the application configuration resource file are JavaServer Faces managed beans, not CDI managed beans.
With the managed bean creation facility, you can
Create beans in one centralized file that is available to the entire application, rather than conditionally instantiate beans throughout the application
Customize a bean's properties without any additional code
Customize a bean's property values directly from within the configuration file so that it is initialized with these values when it is created
Using value
elements, set a property of one managed bean to be the result of evaluating another value expression
This section shows you how to initialize beans using the managed bean creation facility. See Writing Bean Properties and Writing Managed Bean Methods for information on programming managed beans.
A managed bean is initiated in the application configuration resource file using a managed-bean
element, which represents an instance of a bean class that must exist in the application. At runtime, the JavaServer Faces implementation processes the managed-bean
element. If a page references the bean and no bean instance exists, the JavaServer Faces implementation instantiates the bean as specified by the element configuration.
Here is an example managed bean configuration from the Duke's Bookstore case study:
<managed-bean eager="true"> <managed-bean-name>Book201</managed-bean-name> <managed-bean-class>dukesbookstore.model.ImageArea</managed-bean-class> <managed-bean-scope>application</managed-bean-scope> <managed-property> <property-name>shape</property-name> <value>rect</value> </managed-property> <managed-property> <property-name>alt</property-name> <value>Duke</value> </managed-property> <managed-property> <property-name>coords</property-name> <value>67,23,212,268</value> </managed-property> </managed-bean>
The managed-bean-name
element defines the key under which the bean will be stored in a scope. For a component's value to map to this bean, the component tag's value
attribute must match the managed-bean-name
up to the first period.
The managed-bean-class
element defines the fully qualified name of the JavaBeans component class used to instantiate the bean.
The managed-bean
element can contain zero or more managed-property
elements, each corresponding to a property defined in the bean class. These elements are used to initialize the values of the bean properties. If you don't want a particular property initialized with a value when the bean is instantiated, do not include a managed-property
definition for it in your application configuration resource file.
If a managed-bean
element does not contain other managed-bean
elements, it can contain one map-entries
element or list-entries
element. The map-entries
element configures a set of beans that are instances of Map
. The list-entries
element configures a set of beans that are instances of List
.
In the following example, the newsletters
managed bean, representing a UISelectItems
component, is configured as an ArrayList
that represents a set of SelectItem
objects. Each SelectItem
object is in turn configured as a managed bean with properties:
<managed-bean> <managed-bean-name>newsletters</managed-bean-name> <managed-bean-class>java.util.ArrayList</managed-bean-class> <managed-bean-scope>application</managed-bean-scope> <list-entries> <value-class>javax.faces.model.SelectItem</value-class> <value>#{newsletter0}</value> <value>#{newsletter1}</value> <value>#{newsletter2}</value> <value>#{newsletter3}</value> </list-entries> </managed-bean> <managed-bean> <managed-bean-name>newsletter0</managed-bean-name> <managed-bean-class>javax.faces.model.SelectItem</managed-bean-class> <managed-bean-scope>none</managed-bean-scope> <managed-property> <property-name>label</property-name> <value>Duke's Quarterly</value> </managed-property> <managed-property> <property-name>value</property-name> <value>200</value> </managed-property> </managed-bean> ...
This approach may be useful for quick-and-dirty creation of selection item lists before a development team has had time to create such lists from the database. Note that each of the individual newsletter beans has a managed-bean-scope
setting of none
so that they will not themselves be placed into any scope.
See Initializing Array and List Properties for more information on configuring collections as beans.
To map to a property defined by a managed-property
element, you must ensure that the part of a component tag's value
expression after the period matches the managed-property
element's property-name
element. The next section, Initializing Properties Using the managed-property Element, explains in more detail how to use the managed-property
element. See Initializing Managed Bean Properties for an example of initializing a managed bean property.
A managed-property
element must contain a property-name
element, which must match the name of the corresponding property in the bean. A managed-property
element must also contain one of a set of elements that defines the value of the property. This value must be of the same type as that defined for the property in the corresponding bean. Which element you use to define the value depends on the type of the property defined in the bean. Table 16-1 lists all the elements that are used to initialize a value.
Table 16-1 Subelements of managed-property Elements That Define Property Values
| Element | Value It Defines |
|---|---|
|
Defines the values in a list |
|
|
Defines the values of a map |
|
|
Explicitly sets the property to |
|
|
Defines a single value, such as a |
Using the managed-bean Element includes an example of initializing an int
property (a primitive type) using the value
subelement. You also use the value
subelement to initialize String
and other reference types. The rest of this section describes how to use the value
subelement and other subelements to initialize properties of Java Enum
types, Map
, array
, and Collection
, as well as initialization parameters.
A managed bean property can also be a Java Enum
type (see http://docs.oracle.com/javase/7/docs/api/java/lang/Enum.html
). In this case, the value
element of the managed-property
element must be a String
that matches one of the String
constants of the Enum
. In other words, the String
must be one of the valid values that can be returned if you were to call valueOf(Class, String)
on enum
, where Class
is the Enum
class and String
is the contents of the value
subelement. For example, suppose the managed bean property is the following:
public enum Suit { Hearts, Spades, Diamonds, Clubs } ... public Suit getSuit() { ... return Suit.Hearts; }
Assuming you want to configure this property in the application configuration resource file, the corresponding managed-property
element looks like this:
<managed-property> <property-name>Suit</property-name> <value>Hearts</value> </managed-property>
When the system encounters this property, it iterates over each of the members of the enum
and calls toString()
on each member until it finds one that is exactly equal to the value from the value
element.
Another powerful feature of the managed bean creation facility is the ability to reference implicit objects from a managed bean property.
Suppose you have a page that accepts data from a customer, including the customer's address. Suppose also that most of your customers live in a particular area code. You can make the area code component render this area code by saving it in an implicit object and referencing it when the page is rendered.
You can save the area code as an initial default value in the context initParam
implicit object by adding a context parameter to your web application and setting its value in the deployment descriptor. For example, to set a context parameter called defaultAreaCode
to 650
, add a context-param
element to the deployment descriptor and give the parameter the name defaultAreaCode
and the value 650
.
Next, write a managed-bean
declaration that configures a property that references the parameter:
<managed-bean> <managed-bean-name>customer</managed-bean-name> <managed-bean-class>CustomerBean</managed-bean-class> <managed-bean-scope>request</managed-bean-scope> <managed-property> <property-name>areaCode</property-name> <value>#{initParam.defaultAreaCode}</value> </managed-property> ... </managed-bean>
To access the area code at the time the page is rendered, refer to the property from the area
component tag's value
attribute:
<h:inputText id=area value="#{customer.areaCode}"
Values are retrieved from other implicit objects in a similar way.
The map-entries
element is used to initialize the values of a bean property with a type of Map
if the map-entries
element is used within a managed-property
element. A map-entries
element contains an optional key-class
element, an optional value-class
element, and zero or more map-entry
elements.
Each of the map-entry
elements must contain a key
element and either a null-value
or value
element. Here is an example that uses the map-entries
element:
<managed-bean> ... <managed-property> <property-name>prices</property-name> <map-entries> <map-entry> <key>My Early Years: Growing Up on *7</key> <value>30.75</value> </map-entry> <map-entry> <key>Web Servers for Fun and Profit</key> <value>40.75</value> </map-entry> </map-entries> </managed-property> </managed-bean>
The map created from this map-entries
tag contains two entries. By default, all the keys and values are converted to String
. If you want to specify a different type for the keys in the map, embed the key-class
element just inside the map-entries
element:
<map-entries> <key-class>java.math.BigDecimal</key-class> ... </map-entries>
This declaration will convert all the keys into java.math.BigDecimal
. Of course, you must make sure that the keys can be converted to the type you specify. The key from the example in this section cannot be converted to a BigDecimal
, because it is a String
.
If you want to specify a different type for all the values in the map, include the value-class
element after the key-class
element:
<map-entries> <key-class>int</key-class> <value-class>java.math.BigDecimal</value-class> ... </map-entries>
Note that this tag sets only the type of all the value
subelements.
Each map-entry
in the preceding example includes a value
subelement. The value
subelement defines a single value, which will be converted to the type specified in the bean.
Instead of using a map-entries
element, it is also possible to assign the entire map using a value
element that specifies a map-typed expression.
The list-entries
element is used to initialize the values of an array or List
property. Each individual value of the array or List
is initialized using a value
or null-value
element. Here is an example:
<managed-bean> ... <managed-property> <property-name>books</property-name> <list-entries> <value-class>java.lang.String</value-class> <value>Web Servers for Fun and Profit</value> <value>#{myBooks.bookId[3]}</value> <null-value/> </list-entries> </managed-property> </managed-bean>
This example initializes an array or a List
. The type of the corresponding property in the bean determines which data structure is created. The list-entries
element defines the list of values in the array or List
. The value
element specifies a single value in the array or List
and can reference a property in another bean. The null-value
element will cause the setBooks
method to be called with an argument of null
. A null
property cannot be specified for a property whose data type is a Java primitive, such as int
or boolean
.
Sometimes you might want to create a bean that also references other managed beans so that you can construct a graph or a tree of beans. For example, suppose you want to create a bean representing a customer's information, including the mailing address and street address, each of which is also a bean. The following managed-bean
declarations create a CustomerBean
instance that has two AddressBean
properties: one representing the mailing address and the other representing the street address. This declaration results in a tree of beans with CustomerBean
as its root and the two AddressBean
objects as children.
<managed-bean> <managed-bean-name>customer</managed-bean-name> <managed-bean-class> com.example.mybeans.CustomerBean </managed-bean-class> <managed-bean-scope> request </managed-bean-scope> <managed-property> <property-name>mailingAddress</property-name> <value>#{addressBean}</value> </managed-property> <managed-property> <property-name>streetAddress</property-name> <value>#{addressBean}</value> </managed-property> <managed-property> <property-name>customerType</property-name> <value>New</value> </managed-property> </managed-bean> <managed-bean> <managed-bean-name>addressBean</managed-bean-name> <managed-bean-class> com.example.mybeans.AddressBean </managed-bean-class> <managed-bean-scope> none </managed-bean-scope> <managed-property> <property-name>street</property-name> <null-value/> <managed-property> ... </managed-bean>
The first CustomerBean
declaration (with the managed-bean-name
of customer
) creates a CustomerBean
in request scope. This bean has two properties, mailingAddress
and streetAddress
. These properties use the value
element to reference a bean named addressBean
.
The second managed bean declaration defines an AddressBean
but does not create it, because its managed-bean-scope
element defines a scope of none
. Recall that a scope of none
means that the bean is created only when something else references it. Because both the mailingAddress
and the streetAddress
properties reference addressBean
using the value
element, two instances of AddressBean
are created when CustomerBean
is created.
When you create an object that points to other objects, do not try to point to an object with a shorter life span, because it might be impossible to recover that scope's resources when it goes away. A session-scoped object, for example, cannot point to a request-scoped object. And objects with none
scope have no effective life span managed by the framework, so they can point only to other none
-scoped objects. Table 16-2 outlines all of the allowed connections.
Table 16-2 Allowable Connections between Scoped Objects
| An Object of This Scope | May Point to an Object of This Scope |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Be sure not to allow cyclical references between objects. For example, neither of the AddressBean
objects in the preceding example should point back to the CustomerBean
object, because CustomerBean
already points to the AddressBean
objects.
Application messages can include any strings displayed to the user as well as custom error messages (which are displayed by the message
and messages
tags) for your custom converters or validators. To make messages available at application startup time, do one of the following:
Queue an individual message onto the javax.faces.context.FacesContext
instance programmatically, as described in Using FacesMessage to Create a Message
Register all the messages with your application using the application configuration resource file
Here is the section of the faces-config.xml
file that registers the messages for the Duke's Bookstore case study application:
<application> <resource-bundle> <base-name> javaeetutorial.dukesbookstore.web.messages.Messages </base-name> <var>bundle</var> </resource-bundle> <locale-config> <default-locale>en</default-locale> <supported-locale>es</supported-locale> <supported-locale>de</supported-locale> <supported-locale>fr</supported-locale> </locale-config> </application>
This set of elements causes the application to be populated with the messages that are contained in the specified resource bundle.
The resource-bundle
element represents a set of localized messages. It must contain the fully qualified path to the resource bundle containing the localized messages (in this case, dukesbookstore.web.messages.Messages
). The var
element defines the EL name by which page authors refer to the resource bundle.
The locale-config
element lists the default locale and the other supported locales. The locale-config
element enables the system to find the correct locale based on the browser's language settings.
The supported-locale
and default-locale
tags accept the lowercase, two-character codes defined by ISO 639-1 (see http://www.loc.gov/standards/iso639-2/php/English_list.php
). Make sure that your resource bundle actually contains the messages for the locales you specify with these tags.
To access the localized message, the application developer merely references the key of the message from the resource bundle.
You can pull localized text into an alt
tag for a graphic image, as in the following example:
<h:graphicImage id="mapImage" name="book_all.jpg" library="images" alt="#{bundle.ChooseBook}" usemap="#bookMap" />
The alt
attribute can accept value expressions. In this case, the alt
attribute refers to localized text that will be included in the alternative text of the image rendered by this tag.
Instead of registering messages in the application configuration resource file, you can access the java.util.ResourceBundle
directly from managed bean code. The code snippet below locates an email error message:
String message = ""; ... message = ExampleBean.loadErrorMessage(context, ExampleBean.EX_RESOURCE_BUNDLE_NAME, "EMailError"); context.addMessage(toValidate.getClientId(context), new FacesMessage(message));
These lines call the bean's loadErrorMessage
method to get the message from the ResourceBundle
. Here is the loadErrorMessage
method:
public static String loadErrorMessage(FacesContext context, String basename, String key) { if ( bundle == null ) { try { bundle = ResourceBundle.getBundle(basename, context.getViewRoot().getLocale()); } catch (Exception e) { return null; } } return bundle.getString(key); }
A JavaServer Faces page uses the message
or messages
tags to access error messages, as explained in Displaying Error Messages with the h:message and h:messages Tags.
The error messages these tags access include
The standard error messages that accompany the standard converters and validators that ship with the API. (see Section <IP_ADDRESS> of the JavaServer Faces specification for a complete list of standard error messages)
Custom error messages contained in resource bundles registered with the application by the application architect using the resource-bundle
element in the configuration file
When a converter or validator is registered on an input component, the appropriate error message is automatically queued on the component.
A page author can override the error messages queued on a component by using the following attributes of the component's tag:
converterMessage
: References the error message to display when the data on the enclosing component cannot be converted by the converter registered on this component.
requiredMessage
: References the error message to display when no value has been entered into the enclosing component.
validatorMessage
: References the error message to display when the data on the enclosing component cannot be validated by the validator registered on this component.
All three attributes are enabled to take literal values and value expressions. If an attribute uses a value expression, this expression references the error message in a resource bundle. This resource bundle must be made available to the application in one of the following ways:
By the application architect using the resource-bundle
element in the configuration file
By the page author using the f:loadBundle
tag
Conversely, the resource-bundle
element must be used to make available to the application those resource bundles containing custom error messages that are queued on the component as a result of a custom converter or validator being registered on the component.
The following tags show how to specify the requiredMessage
attribute using a value expression to reference an error message:
<h:inputText id="ccno" size="19" required="true" requiredMessage="#{customMessages.ReqMessage}"> ... </h:inputText> <h:message styleClass="error-message" for="ccno"/>
The value expression used by requiredMessage
in this example references the error message with the ReqMessage
key in the resource bundle customMessages
.
This message replaces the corresponding message queued on the component and will display wherever the message
or messages
tag is placed on the page.
In addition to the validators you declare on the components, you can also specify zero or more default validators in the application configuration resource file. The default validator applies to all javax.faces.component.UIInput
instances in a view or component tree and is appended after the local defined validators. Here is an example of a default validator registered in the application configuration resource file:
<faces-config> <application> <default-validators> <validator-id>javax.faces.Bean</validator-id> </default-validators> <application/> </faces-config>
If the application developer provides an implementation of the javax.faces.validator.Validator
interface to perform validation, you must register this custom validator either by using the @FacesValidator
annotation, as described in Implementing the Validator Interface, or by using the validator
XML element in the application configuration resource file:
<validator> ... <validator-id>FormatValidator</validator-id> <validator-class> myapplication.validators.FormatValidator </validator-class> <attribute> ... <attribute-name>formatPatterns</attribute-name> <attribute-class>java.lang.String</attribute-class> </attribute> </validator>
Attributes specified in a validator
tag override any settings in the @FacesValidator
annotation.
The validator-id
and validator-class
elements are required subelements. The validator-id
element represents the identifier under which the Validator
class should be registered. This ID is used by the tag class corresponding to the custom validator
tag.
The validator-class
element represents the fully qualified class name of the Validator
class.
The attribute
element identifies an attribute associated with the Validator
implementation. It has required attribute-name
and attribute-class
subelements. The attribute-name
element refers to the name of the attribute as it appears in the validator
tag. The attribute-class
element identifies the Java type of the value associated with the attribute.
Creating and Using a Custom Validator explains how to implement the Validator
interface.
Using a Custom Validator explains how to reference the validator from the page.
As is the case with a custom validator, if the application developer creates a custom converter, you must register it with the application either by using the @FacesConverter
annotation, as described in Creating a Custom Converter, or by using the converter
XML element in the application configuration resource file. Here is a hypothetical converter
configuration for CreditCardConverter
from the Duke's Bookstore case study:
<converter> <description> Converter for credit card numbers that normalizes the input to a standard format </description> <converter-id>CreditCardConverter</converter-id> <converter-class> dukesbookstore.converters.CreditCardConverter </converter-class> </converter>
Attributes specified in a converter
tag override any settings in the @FacesConverter
annotation.
The converter
element represents a javax.faces.convert.Converter
implementation and contains required converter-id
and converter-class
elements.
The converter-id
element identifies an ID that is used by the converter
attribute of a UI component tag to apply the converter to the component's data. Using a Custom Converter includes an example of referencing the custom converter from a component tag.
The converter-class
element identifies the Converter
implementation.
Creating and Using a Custom Converter explains how to create a custom converter.
Navigation between different pages of a JavaServer Faces application, such as choosing the next page to be displayed after a button or link component is clicked, is defined by a set of rules. Navigation rules can be implicit, or they can be explicitly defined in the application configuration resource file. For more information on implicit navigation rules, see Navigation Model.
Each navigation rule specifies how to navigate from one page to another page or set of pages. The JavaServer Faces implementation chooses the proper navigation rule according to which page is currently displayed.
After the proper navigation rule is selected, the choice of which page to access next from the current page depends on two factors:
The outcome can be anything the developer chooses, but Table 16-3 lists some outcomes commonly used in web applications.
Table 16-3 Common Outcome Strings
| Outcome | What It Means |
|---|---|
|
|
Everything worked. Go on to the next page. |
|
|
Something is wrong. Go on to an error page. |
|
|
The user needs to log in first. Go on to the login page. |
|
|
The search did not find anything. Go to the search page again. |
Usually, the action method performs some processing on the form data of the current page. For example, the method might check whether the user name and password entered in the form match the user name and password on file. If they match, the method returns the outcome success
. Otherwise, it returns the outcome failure
. As this example demonstrates, both the method used to process the action and the outcome returned are necessary to determine the correct page to access.
Here is a navigation rule that could be used with the example just described:
<navigation-rule> <from-view-id>/login.xhtml</from-view-id> <navigation-case> <from-action>#{LoginForm.login}</from-action> <from-outcome>success</from-outcome> <to-view-id>/storefront.xhtml</to-view-id> </navigation-case> <navigation-case> <from-action>#{LoginForm.logon}</from-action> <from-outcome>failure</from-outcome> <to-view-id>/logon.xhtml</to-view-id> </navigation-case> </navigation-rule>
This navigation rule defines the possible ways to navigate from login.xhtml
. Each navigation-case
element defines one possible navigation path from login.xhtml
. The first navigation-case
says that if LoginForm.login
returns an outcome of success
, then storefront.xhtml
will be accessed. The second navigation-case
says that login.xhtml
will be re-rendered if LoginForm.login
returns failure
.
The configuration of an application's page flow consists of a set of navigation rules. Each rule is defined by the navigation-rule
element in the faces-config.xml
file.
Each navigation-rule
element corresponds to one component tree identifier defined by the optional from-view-id
element. This means that each rule defines all the possible ways to navigate from one particular page in the application. If there is no from-view-id
element, the navigation rules defined in the navigation-rule
element apply to all the pages in the application. The from-view-id
element also allows wildcard matching patterns. For example, this from-view-id
element says that the navigation rule applies to all the pages in the books
directory:
<from-view-id>/books/*</from-view-id>
A navigation-rule
element can contain zero or more navigation-case
elements. The navigation-case
element defines a set of matching criteria. When these criteria are satisfied, the application will navigate to the page defined by the to-view-id
element contained in the same navigation-case
element.
The navigation criteria are defined by optional from-outcome
and from-action
elements. The from-outcome
element defines a logical outcome, such as success
. The from-action
element uses a method expression to refer to an action method that returns a String
, which is the logical outcome. The method performs some logic to determine the outcome and returns the outcome.
The navigation-case
elements are checked against the outcome and the method expression in the following order.
Cases specifying both a from-outcome
value and a from-action
value. Both of these elements can be used if the action method returns different outcomes depending on the result of the processing it performs.
Cases specifying only a from-outcome
value. The from-outcome
element must match either the outcome defined by the action
attribute of the javax.faces.component.UICommand
component or the outcome returned by the method referred to by the UICommand
component.
Cases specifying only a from-action
value. This value must match the action
expression specified by the component tag.
When any of these cases is matched, the component tree defined by the to-view-id
element will be selected for rendering.
When the application developer creates a custom renderer, as described in Delegating Rendering to a Renderer, you must register it using the appropriate render kit. Because the image map application implements an HTML image map, the AreaRenderer
and MapRenderer
classes in the Duke's Bookstore case study should be registered using the HTML render kit.
You register the renderer either by using the @FacesRenderer
annotation, as described in Creating the Renderer Class, or by using the render-kit
element of the application configuration resource file. Here is a hypothetical configuration of AreaRenderer
:
<render-kit> <renderer> <component-family>Area</component-family> <renderer-type>DemoArea</renderer-type> <renderer-class> dukesbookstore.renderers.AreaRenderer </renderer-class> <attribute> <attribute-name>onmouseout</attribute-name> <attribute-class>java.lang.String</attribute-class> </attribute> <attribute> <attribute-name>onmouseover</attribute-name> <attribute-class>java.lang.String</attribute-class> </attribute> <attribute> <attribute-name>styleClass</attribute-name> <attribute-class>java.lang.String</attribute-class> </attribute> </renderer> ...
Attributes specified in a renderer
tag override any settings in the @FacesRenderer
annotation.
The render-kit
element represents a javax.faces.render.RenderKit
implementation. If no render-kit-id
is specified, the default HTML render kit is assumed. The renderer
element represents a javax.faces.render.Renderer
implementation. By nesting the renderer
element inside the render-kit
element, you are registering the renderer with the RenderKit
implementation associated with the render-kit
element.
The renderer-class
is the fully qualified class name of the Renderer
.
The component-family
and renderer-type
elements are used by a component to find renderers that can render it. The component-family
identifier must match that returned by the component class's getFamily
method. The component family represents a component or set of components that a particular renderer can render. The renderer-type
must match that returned by the getRendererType
method of the tag handler class.
By using the component family and renderer type to look up renderers for components, the JavaServer Faces implementation allows a component to be rendered by multiple renderers and allows a renderer to render multiple components.
Each of the attribute
tags specifies a render-dependent attribute and its type. The attribute
element doesn't affect the runtime execution of your application. Rather, it provides information to tools about the attributes the Renderer
supports.
The object responsible for rendering a component (be it the component itself or a renderer to which the component delegates the rendering) can use facets to aid in the rendering process. These facets allow the custom component developer to control some aspects of rendering the component. Consider this custom component tag example:
<d:dataScroller> <f:facet name="header"> <h:panelGroup> <h:outputText value="Account Id"/> <h:outputText value="Customer Name"/> <h:outputText value="Total Sales"/> </h:panelGroup> </f:facet> <f:facet name="next"> <h:panelGroup> <h:outputText value="Next"/> <h:graphicImage url="/images/arrow-right.gif" /> </h:panelGroup> </f:facet> ... </d:dataScroller>
The dataScroller
component tag includes a component that will render the header and a component that will render the Next button. If the renderer associated with this component renders the facets, you can include the following facet
elements in the renderer
element:
<facet> <description>This facet renders as the header of the table. It should be a panelGroup with the same number of columns as the data. </description> <display-name>header</display-name> <facet-name>header</facet-name> </facet> <facet> <description>This facet renders as the content of the "next" button in the scroller. It should be a panelGroup that includes an outputText tag that has the text "Next" and a right arrow icon. </description> <display-name>Next</display-name> <facet-name>next</facet-name> </facet>
If a component that supports facets provides its own rendering and you want to include facet
elements in the application configuration resource file, you need to put them in the component's configuration rather than the renderer's configuration.
In addition to registering custom renderers (as explained in the preceding section), you also must register the custom components that are usually associated with the custom renderers. You use either a @FacesComponent
annotation, as described in Creating Custom Component Classes, or the component
element of the application configuration resource file.
Here is a hypothetical component
element from the application configuration resource file that registers AreaComponent
:
<component> <component-type>DemoArea</component-type> <component-class> dukesbookstore.components.AreaComponent </component-class> <property> <property-name>alt</property-name> <property-class>java.lang.String</property-class> </property> <property> <property-name>coords</property-name> <property-class>java.lang.String</property-class> </property> <property> <property-name>shape</property-name> <property-class>java.lang.String</property-class> </property> </component>
Attributes specified in a component
tag override any settings in the @FacesComponent
annotation.
The component-type
element indicates the name under which the component should be registered. Other objects referring to this component use this name. For example, the component-type
element in the configuration for AreaComponent
defines a value of DemoArea
, which matches the value returned by the AreaTag
class's getComponentType
method.
The component-class
element indicates the fully qualified class name of the component. The property
elements specify the component properties and their types.
If the custom component can include facets, you can configure the facets in the component configuration using facet
elements, which are allowed after the component-class
elements. See Registering a Custom Renderer with a Render Kit for further details on configuring facets.
In addition to configuring your application, you must satisfy other requirements of JavaServer Faces applications, including properly packaging all the necessary files and providing a deployment descriptor. This section describes how to perform these administrative tasks.
JavaServer Faces applications can be packaged in a WAR file, which must conform to specific requirements to execute across different containers. At a minimum, a WAR file for a JavaServer Faces application may contain the following:
A web application deployment descriptor, called web.xml
, to configure resources required by a web application (required)
A specific set of JAR files containing essential classes (optional)
A set of application classes, JavaServer Faces pages, and other required resources, such as image files
A WAR file may also contain:
An application configuration resource file, which configures application resources
A set of tag library descriptor files
For example, a Java Server Faces web application WAR file using Facelets typically has the following directory structure:
$PROJECT_DIR [Web Pages] +- /[xhtml or html documents] +- /resources +- /WEB-INF +- /web.xml +- /beans.xml (optional) +- /classes (optional) +- /lib (optional) +- /faces-config.xml (optional) +- /*.taglib.xml (optional) +- /glassfish-web.xml (optional)
The web.xml
file (or web deployment descriptor), the set of JAR files, and the set of application files must be contained in the WEB-INF
directory of the WAR file.
Web applications are commonly configured using elements contained in the web application deployment descriptor, web.xml
. The deployment descriptor for a JavaServer Faces application must specify certain configurations, including the following:
The servlet used to process JavaServer Faces requests
The servlet mapping for the processing servlet
The path to the configuration resource file, if it exists and is not located in a default location
The deployment descriptor can also include other, optional configurations, such as those that
Specify where component state is saved
Encrypt state saved on the client
Compress state saved on the client
Restrict access to pages containing JavaServer Faces tags
Turn on XML validation
Specify the Project Stage
Verify custom objects
This section gives more details on these configurations. Where appropriate, it also describes how you can make these configurations using NetBeans IDE.
A requirement of a JavaServer Faces application is that all requests to the application that reference previously saved JavaServer Faces components must go through javax.faces.webapp.FacesServlet
. A FacesServlet
instance manages the request-processing lifecycle for web applications and initializes the resources required by JavaServer Faces technology.
Before a JavaServer Faces application can launch its first web page, the web container must invoke the FacesServlet
instance in order for the application lifecycle process to start. See The Lifecycle of a JavaServer Faces Application for more information.
The following example shows the default configuration of the FacesServlet
:
<servlet> <servlet-name>Faces Servlet</servlet-name> <servlet-class>javax.faces.webapp.FacesServlet</servlet-class> </servlet>
You will provide a mapping configuration entry to make sure that the FacesServlet
instance is invoked. The mapping to FacesServlet
can be a prefix mapping, such as /faces/*
, or an extension mapping, such as *.xhtml
. The mapping is used to identify a page as having JavaServer Faces content. Because of this, the URL to the first page of the application must include the URL pattern mapping.
The following elements specify a prefix mapping:
<servlet-mapping> <servlet-name>Faces Servlet</servlet-name> <url-pattern>/faces/*</url-pattern> </servlet-mapping> ... <welcome-file-list> <welcome-file>faces/greeting.xhtml</welcome-file> </welcome-file-list>
The following elements, used in the tutorial examples, specify an extension mapping:
<servlet-mapping> <servlet-name>Faces Servlet</servlet-name> <url-pattern>*.xhtml</url-pattern> </servlet-mapping> ... <welcome-file-list> <welcome-file>index.xhtml</welcome-file> </welcome-file-list>
When you use this mechanism, users access the application as shown in the following example:
http://localhost:8080/guessNumber
In the case of extension mapping, if a request comes to the server for a page with an .xhtml
extension, the container will send the request to the FacesServlet
instance, which will expect a corresponding page of the same name containing the content to exist.
If you are using NetBeans IDE to create your application, a web deployment descriptor is automatically created for you with default configurations. If you created your application without an IDE, you can create a web deployment descriptor.
As explained in Application Configuration Resource File, an application can have multiple application configuration resource files. If these files are not located in the directories that the implementation searches by default or the files are not named faces-config.xml
, you need to specify paths to these files.
To specify these paths using NetBeans IDE, do the following.
Expand the node of your project in the Projects tab.
Expand the Web Pages and WEB-INF nodes that are under the project node.
Double-click web.xml
.
After the web.xml
file appears in the editor, click General at the top of the editor window.
Expand the Context Parameters node.
Click Add.
In the Add Context Parameter dialog box:
Enter javax.faces.CONFIG_FILES
in the Parameter Name field.
Enter the path to your configuration file in the Parameter Value field.
Click OK.
Repeat steps 1 through 7 for each configuration file.
For all the components in a web application, you can specify in your deployment descriptor where you want the state to be saved, on either client or server. You do this by setting a context parameter in your deployment descriptor. By default, state is saved on the server, so you need to specify this context parameter only if you want to save state on the client. See Saving and Restoring State for information on the advantages and disadvantages of each location.
To specify where state is saved using NetBeans IDE, do the following.
Expand the node of your project in the Projects tab.
Expand the Web Pages and WEB-INF nodes under the project node.
Double-click web.xml
.
After the web.xml
file appears in the editor window, click General at the top of the editor window.
Expand the Context Parameters node.
Click Add.
In the Add Context Parameter dialog box:
Enter javax.faces.STATE_SAVING_METHOD
in the Parameter Name field.
Enter client
or server
in the Parameter Value field.
Click OK.
If state is saved on the client, the state of the entire view is rendered to a hidden field on the page. The JavaServer Faces implementation saves the state on the server by default. Duke's Forest saves its state on the client.
Project Stage is a context parameter identifying the status of a JavaServer Faces application in the software lifecycle. The stage of an application can affect the behavior of the application. For example, error messages can be displayed during the Development stage but suppressed during the Production stage.
The possible Project Stage values are as follows:
Development
UnitTest
SystemTest
Production
Project Stage is configured through a context parameter in the web deployment descriptor file. Here is an example:
<context-param> <param-name>javax.faces.PROJECT_STAGE</param-name> <param-value>Development</param-value> </context-param>
If no Project Stage is defined, the default stage is Production
. You can also add custom stages according to your requirements.
When packaging web applications using the included build scripts, you'll notice that the scripts package resources in the following ways.
All web pages are placed at the top level of the WAR file.
The faces-config.xml
file and the web.xml
file are packaged in the WEB-INF
directory.
All packages are stored in the WEB-INF/classes/
directory.
All application JAR files are packaged in the WEB-INF/lib/
directory.
All resource files are either under the root of the web application /resources
directory or in the web application's classpath, the META-INF/resources/
resourceIdentifier directory. For more information on resources, see Web Resources.
When packaging your own applications, you can use NetBeans IDE or you can use XML files such as those created for Maven. You can modify the XML files to fit your situation. However, you can continue to package your WAR files by using the directory structure described in this section, because this technique complies with the commonly accepted practice for packaging web applications.


教父
posted on 12 Oct 2015 under category movie
《教父》是派拉蒙影业公司出品的一部黑帮题材的电影，改编自马里奥·普佐的同名小说，由弗朗西斯·福特·科波拉执导，马龙·白兰度、阿尔·帕西诺等主演。虽是黑邦电影但它对家庭，对生活，对原则的做出了更好诠释。共有三部，前两部在IMDB电影排行榜中分别排第二与第三. 并且分别获得46，47届奥斯卡。
speak softely love 是我最喜欢的一首歌，也许是因为自己在心情低落的时候看的这部电影，而其中的音乐每次听着都特别伤心，特别心痛。介绍给你们。
一些经典语录
Behind every great fortune,there is a crime 财富背后都是罪恶
Don’t hate your enemy, or you will make wrong judgment.不要恨你的敌人，那样会让你做错误的决定
keep your friends close, but your enemies closer，与你的朋友保持亲近，但要与你的敌人更亲近
Don’t let anybody know what you are thinking. 不要让别人知道你在想什么
Never tell anybody outside the family what you are thinking again 不要让家庭以外的人知道你在想什么
Great men are not born great,they grow great 伟大的人不是天生的，而是后天形成的
You make the choice, and this is your price.你每做一个决定，就有代价
Everything I do with my power, including something criminal, I just want to protect my family and my friends . 我用我的权力做的每一件事（包括犯罪），仅仅是想保护我的家庭和我的朋友
I don’t care what you did is right or wrong, I want you know only me have the right to make decision, cause I am the godfather until my death. 我并不关心你做的对还是错，我只想要你知道只有我才有权做出决定，因为直到我死之前都是教父
I will never do anything guilty. 我从来都没有感觉到愧疚
Do you spend time with your family? Good. Because a man that doesn't spend time with his family can never be a real man.
I spent my whole life trying not to be careless. Women and children can be careless. But not men.我试着不去精心，只有女人与小孩才可以精心。
I'm gonna make him an offer he can't refuse. 我出的价格他是无法拒绝的
I never wanted this for you. I work my whole life — I don't apologize — to take care of my family, and I refused to be a fool, dancing on the string held by all those big shots. I don't apologize — that's my life — but I thought that, that when it was your time, that you would be the one to hold the string. Senator


Pac-Man is a maze arcade game developed and released by Namco in 1980. The original Japanese title of Puck Man was changed to Pac-Man for international releases as a preventative measure against defacement of the arcade machines
by changing the P to an F. Outside Japan, the game was published by Midway Games as part of its licensing agreement with Namco America
HexGL is a futuristic, fast-paced racing game built by Thibaut Despoulain using HTML5, Javascript and WebGL and a tribute to the original Wipeout
and F-Zero series.
2048 is a single-player sliding block puzzle game designed by the Italian web developer Gabriele Cirulli. The game's objective is to slide numbered tiles on a grid to combine them to create a tile with the number 2048. However,
one can continue to play the game after reaching the goal, creating tiles with larger numbers.


Description of the problem:
Ferrero Ukraine is an international confectionery company with a wide geography of representative offices throughout the country. In order to improve the quality of control over their work, the company has a need to modernize its reporting system for regional managers, a system for analyzing sales volumes by areas, trading agents, products.
Functional requirements
1
Reporting system
Develop and deploy in a convenient place for you with the help of a single
2
Integration of the system with other services
Develop and deploy in a convenient place for you with the help of a single
3
Mobile Access
Develop and deploy in a convenient place for you with the help of a single. Develop and deploy in a convenient place for you with the help of a single. Develop and deploy in a convenient place for you with the help of a single
4
Fast data exchange
Develop and deploy in a convenient place for you with the help of a single
5
Fast data exchange
Develop and deploy in a convenient place for you with the help of a single. Develop and deploy in a convenient place for you with the help of a single
Decision
Portal for working with financial documents
- Creating orders and invoice accounts
- Reducing the time for report generation
- Access to data on stock balances in stock
- Mobile access to the service
- Compliance with security policies
- An accessible and understandable user interface
Technologies used
From the speed and effectiveness of the work of employees depends ovn the development of business. Creation of personal


Class: Aws::IAM::Role
| Relationships & Source Files | |
| Super Chains via Extension / Inclusion / Inheritance | |
|
Class Chain:
|
|
|
Instance Chain:
|
|
| Inherits: |
Aws::Resources::Resource
|
| Defined in: | (unknown) |
Class Attribute Summary
::Aws::Resources::Resource - Inherited
Class Method Summary
- .new(name, options = {}) constructor
::Aws::Resources::Resource - Inherited
| .add_data_attribute | Registers a data attribute. |
| .add_identifier, .data_attributes, .identifiers, .new |
::Aws::Resources::OperationMethods - Extended
Instance Attribute Summary
-
#arn ⇒ String
readonly
The Amazon Resource Name (ARN) specifying the role.
-
#assume_role_policy_document ⇒ String
readonly
The policy that grants an entity permission to assume the role.
. -
#create_date ⇒ Time
readonly
The date and time, in ISO 8601 date-time format, when the role was created.
. - #name ⇒ String readonly
-
#path ⇒ String
readonly
The path to the role.
-
#role_id ⇒ String
readonly
The stable and unique string identifying the role.
-
#role_name ⇒ String
readonly
The friendly name that identifies the role.
.
::Aws::Resources::Resource - Inherited
| #client | Marked private to prevent double documentation. |
| #data_loaded?, | |
| #identifiers | Marked private to prevent double documentation. |
Instance Method Summary
- #assume_role_policy ⇒ AssumeRolePolicy
-
#attach_policy(options = {}) ⇒ Struct
Attaches the specified managed policy to the specified IAM role.
. -
#attached_policies(options = {}) ⇒ Collection<Policy>
Returns a Collection of Policy resources.
-
#delete ⇒ Struct
Deletes the specified role.
-
#detach_policy(options = {}) ⇒ Struct
Removes the specified managed policy from the specified role.
. -
#instance_profiles(options = {}) ⇒ Collection<InstanceProfile>
Returns a Collection of InstanceProfile resources.
-
#policies(options = {}) ⇒ Collection<RolePolicy>
Returns a Collection of RolePolicy resources.
- #policy(name) ⇒ RolePolicy
::Aws::Resources::Resource - Inherited
| #data, | |
| #load | Loads data for this resource. |
| #reload | Alias for Resources::Resource#load. |
| #wait_until | Waiter polls an API operation until a resource enters a desired state. |
Constructor Details
.new(name, options = {})
.new(options = {})
Instance Attribute Details
#arn ⇒ String
(readonly)
The Amazon Resource Name (ARN) specifying the role. For more information about ARNs and how to use them in policies, see IAM Identifiers in the Using IAM guide.
#assume_role_policy_document ⇒ String
(readonly)
The policy that grants an entity permission to assume the role.
#create_date ⇒ Time
(readonly)
The date and time, in ISO 8601 date-time format, when the role was created.
#name ⇒ String
(readonly)
#path ⇒ String
(readonly)
The path to the role. For more information about paths, see IAM Identifiers in the Using IAM guide.
#role_id ⇒ String
(readonly)
The stable and unique string identifying the role. For more information about IDs, see IAM Identifiers in the Using IAM guide.
#role_name ⇒ String
(readonly)
The friendly name that identifies the role.
Instance Method Details
#assume_role_policy ⇒ AssumeRolePolicy
#attach_policy(options = {}) ⇒ Struct
Attaches the specified managed policy to the specified IAM role.
When you attach a managed policy to a role, the managed policy becomes part of the role's permission (access) policy. You cannot use a managed policy as the role's trust policy. The role's trust policy is created at the same time as the role, using CreateRole. You can update a role's trust policy using UpdateAssumeRolePolicy.
Use this API to attach a managed policy to a role. To embed an inline policy in a role, use PutRolePolicy. For more information about policies, see Managed Policies and Inline Policies in the IAM User Guide.
#attached_policies(options = {}) ⇒ Collection
<Policy>
Returns a Collection of Policy resources. No API requests are made until you call an enumerable method on the collection. Client#list_attached_role_policies will be called multiple times until every Policy has been yielded.
#delete ⇒ Struct
Deletes the specified role. The role must not have any policies attached. For more information about roles, go to Working with Roles.
Make sure you do not have any Amazon EC2 instances running with the role you are about to delete. Deleting a role or instance profile that is associated with a running instance will break any applications running on the instance.
#detach_policy(options = {}) ⇒ Struct
Removes the specified managed policy from the specified role.
A role can also have inline policies embedded with it. To delete an inline policy, use the DeleteRolePolicy API. For information about policies, see Managed Policies and Inline Policies in the IAM User Guide.
#instance_profiles(options = {}) ⇒ Collection
<InstanceProfile>
Returns a Collection of InstanceProfile resources. No API requests are made until you call an enumerable method on the collection. Client#list_instance_profiles_for_role will be called multiple times until every InstanceProfile has been yielded.
#policies(options = {}) ⇒ Collection
<RolePolicy>
Returns a Collection of RolePolicy resources. No API requests are made until you call an enumerable method on the collection. Client#list_role_policies will be called multiple times until every RolePolicy has been yielded.