The primary topics in CoreJSF Chapter 2 are managed JSF beans and internationalization using JSF string management. JSF beans are Java beans with management support from the JSF framework.
A Java bean is just an object that observes naming conventions to define the properties of the object.
Bean properties are defined by writing getter and setter methods. For a property named myProperty the methods are named
Note that the first letter of the property name is capitalized in the getter and setter method names.
Getter methods have no parameters. Setter methods have a single parameter - the new value for the property. The return type of the getter and the type of the setter parameter define the type of the property. They should be the same.
A Java bean can have read-write access, read-only access, or write-only access. The allowed access is determined by which of the access methods is defined:
Read-only properties are useful for properties that are either
The primary mechanism for handling data in a JSF application is a Java bean. A JSF application may have ordinary Java beans and in addition it can have JSF managed beans.
A JSF managed bean is accessible from JSF pages. It is defined in a Java class file that
The JSF managed beans are created and destroyed according to their scope. They can be accessed in the JSF pages using value expressions.
JSF has had managed beans since its earlier days. In JSF 2.0, Contexts and Dependency Injection (CDI) was introduced. This provides an easier mechanism for bean management. This presentation only describes CDI management mechanisms.
A JSF bean is given a scope with a Java annotation similar to the following.
@SessionScope
Among the scopes that can be declared are:
This web presentation only intends to give a brief overview of when to use these scopes. Except for session scope mechanics of their use should be learned only as needed.
@ApplicationScope
Application scope is useful for keeping track of application usage statistics. For example, web application developers may want to track user errors to determine what parts of a web application need improved user interactions or better explanation.
It lasts for the duration of the web application.
It is shared among all requests and all sessions.
@SessionScope
Session scope is the most common scope. Beginning web application developers should only use session scope.
It lasts during repeated connections by the same client.
Session tracking is usually done with cookies or through URL rewriting and session IDs. The mechanism is transparent to web application developers.
@RequestScope
Request scope is usually an optimization for reducing the resources used by a web application.
It is short-lived; a new instance created with each request.
It is not appropriate if data is to persist beyond the request.
@ViewScope
View scope is associated with individual JSF pages.
@ConversationScope
Conversation scope allows web application developers to define their own scopes. It has a mechanism that programmers can use to determine when the scope begins and when it ends.
Bean configuration can be done either with annotations in Java class files or with the file beans.xml. In earlier versions of JSF configuration with beans.xml was required for some purposes. With JSF 2.0, this file can be left empty (it is still required) and the configuration can be done in the Java class files.
Value expressions are used in JSF pages to reference bean properties and methods. They are also used for accessing strings in resource bundles. Their legal syntax depends on how they are used.
Value expressions in a JSF page may invoke either getters or setters for bean properties or they may invoke other bean methods.
The simplest for of a property expression just names the bean and one of its properties using the following syntax.
#{bean-name.property-name}
In an rvalue context these simple expressions can be combined with some simple operators.
Method expressions are useful for action attributes of <h:commandButton> tags. They have the following syntax.
#{bean-name.method-name(arguments)}
When used in tag attributes, String arguments should be enclosed in single quotes when the entire value expression is double quoted.
Advanced expressions should only be learned as needed. See CoreJSF pp. 63-71 to get a sense of what is available.
You can specify the strings appearing in a web application using a properties file. This makes it easier to change the strings.
JSF also provides an internationalization mechanism that selects a properties file from a message bundle based on locale preference information sent by a browser. To use this mechanism you must declare the message bundle in a configuration file.
To manage the strings displayed on pages, they can be stored in a properties file. A properties file consists of a line for each string that it defines. Each line has the form
string-name=string-value
The string-value is substituted for string-name wherever it appears in a web page.
A properties file is typically stored in a Java source package. It must have the .properties extension.
A message bundle is a group of properties files, one for each supported locale. They all define the same string names but have different values for different locales. The JSF framework uses a file naming convention to select the appropriate properties file. Each file name has the form bundle-name_locale-suffix.properties. The locale-suffix part is omitted for the default locale.
You declare a message bundle in the faces-config.xml. There, the resource bundle files are specified and the bundle is given a name for use in the JSF pages.
A bundle string is accessed in a JSF page using the notation #{bundle-name.string-name}.