SeamFramework.orgCommunity Documentation

Chapter 7. Faces View Configuration

7.1. Configuration With Annotated Enums
7.2. Configuring View Restrictions
7.2.1. Writing Seam security Annotations
7.2.2. Applying the Security Restrictions
7.2.3. Changing the Restriction Phases
7.3. Configuring URL Rewriting
7.4. Configuring "faces-redirect"
7.5. Configuring Transactional Views

Seam Faces aims to provide JSF web developers with a truly worthy framework for web development by ironing out some of the JSF pain points, integrating tightly with CDI, and offering out of the box integration with the other Seam Modules. The view configuration presented here provides a central means of configuring seemingly disparate concerns.

Adhering to the CDI core tenet of type safety, Seam Faces offers a type-safe way to configure the behaviour of your JSF views. So far these configurable behaviors include:

The Seam Faces example application faces-viewconfig, demonstrates all the view configuration techniques discussed in this chapter.

Faces pages are configured by placing annotations on the properties of an Java enum. The annotation @ViewConfig is placed on a Java interface, which contains a static enum. It is the properties of this static enum that hold the individual annotations used to configure the view.

public interface Pages {
    static enum Pages1 {

The interface containing the enum is required due to a limitation in version 1.0 of the CDI specification. If the @ViewConfig is placed directly on the enum, the CDI specification does not require the annotations to be scanned.

Each property of the enum is annotated with at least the @ViewPattern annotation. This view pattern is used to match against the JSF view ids, to determine which annotations apply to a given view id. The view patterns themselves support the * wild character. A view is matched against all view parameters that apply to determine the relevant annotations. If conflicting annotations are found, the annotation paired with the most specific matching view pattern takes precedence.

Securing view access is achieved through integration with Seam Security, which must be explicitly bundled with your web application. Refer to the Seam Security documentation for details on how to setup authentication. What we'll cover here is the authorisation to JSF views.

Seam Faces delegates URL Rewriting to Pretty Faces. The Rewriting mechanism however is pluggable, and an alternate URL Rewriting engine could easily be used instead. What makes SeamFaces unique in it's approach to URL rewriting, is that the rewrite configuration is done via the @ViewConfig mechanism, so all view configuration is done consistently.

To configure UrlRewriting, use the @UrlRewrite Seam Faces annotation:


The above listing would rewrite the url /item.jsf/item=2 into /item/2/. See the Pretty Faces documentation for further details on configuring URL rewriting.

A @ViewPattern annotated with @FacesRedirect will cause all navigations to views that match that pattern to have their faces-redirect property set to true. This alleviates the requirement to append ?faces-redirect=true to all implicit navigation rules, and neither does it have to be specified in the navigation rules defined in the faces-config.xml.

Through integration with Seam Persistence, the transactional behaviour of the JSF lifecycle can be configured through the @ViewConfig mechanism. More details will be provided here, as this feature is fleshed out.