HTML and CSS Reference
In-Depth Information
Listing 5-22.
File Layout of a Flow Residing Inside a JAR File
| META-INF/flows/beans.xml
| META-INF/faces-config.xml
| META-INF/flows/newEntryFlow/newEntryFlow-flow.xml
| META-INF/flows/newEntryFlow/newEntryHelp.xhtml
| META-INF/flows/newEntryFlow/create-entry-1.xhtml
| META-INF/flows/newEntryFlow/create-entry-2.xhtml
| META-INF/flows/newEntryFlow/create-entry-3.xhtml
| META-INF/flows/modifyEntryFlow/modifyEntryFlow-flow.xml
| META-INF/flows/modifyEntryFlow/modifyEntryHelp.xhtml
| META-INF/flows/modifyEntryFlow/modify-entry-1.xhtml
| META-INF/flows/modifyEntryFlow/modify-entry-2.xhtml
| META-INF/flows/modifyEntryFlow/modify-entry-3.xhtml
| myflow/NewEntryFlow.class
| myflow/ModifyEntryFlow.class
Stateless Views
When requesting a view, JSF normally checks if a copy of the state is available (on either the server or client depending
on the value of the
javax.faces.STATE_SAVING_METHOD
context parameter). If the requested view doesn't exist, it is
created and details about the components in the view are stored for later retrieval and processing. In some situations
the view may have expired and you will receive the dreaded
ViewExpiredException
. All the processing involved in
saving and restoring views contributes to unwanted overhead in high-load applications. JSF 2.2 introduced a simple
but powerful feature called stateless views. With stateless views you can specify views whose state should not be
managed. Instead, the state of the view is set to the initial state every time it is requested. You mark a view as stateless
by setting the
transient
attribute on
<f:view />
to
true
. When using stateless views you should be careful not to
depend on any state-based scope such as
@ViewScope
and
@SessionScope
. Using these scopes in conjunction with
stateless views will end up giving you unpredictable behaviors. With JSF Development mode enabled, you will see
warnings in the bottom of the page when you combine state-based scopes and stateless views. Note that stateless
views do not mean that you can store data in your backing beans. In fact, you must store your data in managed beans
if you want to persist any data while using stateless views. A classical example of a stateless view is a login page.
The login page doesn't keep track of state and only needs to store information such as username and password in a
managed bean (with container-managed security not even a managed bean is necessary for persisting the user input).
Listing 5-23 shows an example of a stateless view for a newsletter sign-up page. Once the page has been submitted
there is no need to retain the view and it is therefore a good candidate for a stateless view.
Listing 5-23.
Stateless View for Signing Up for a Newsletter
<?xml version='1.0' encoding='UTF-8' ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
<html xmlns="
http://www.w3.org/1999/xhtml
"
xmlns:h="
http://xmlns.jcp.org/jsf/html
"
xmlns:ui="
http://xmlns.jcp.org/jsf/facelets
"
xmlns:f="
http://xmlns.jcp.org/jsf/core
"
>
<f:view transient="true">
<ui:composition template="/page-template.xhtml">
<ui:define name="page-title">Newsletter Sign-up</ui:define>
<ui:define name="content">
