Overview | Package | Class | Use | Tree | Deprecated | Index | Help
PREV CLASS NEXT CLASS | FRAMES NO FRAMES
SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD

## org.apache.myfaces.orchestra.viewController
Class DefaultViewControllerNameMapper

    java.lang.Object
      org.apache.myfaces.orchestra.viewController.DefaultViewControllerNameMapper

All Implemented Interfaces:
  ViewControllerNameMapper

    public class DefaultViewControllerNameMapper

extends java.lang.Object
implements ViewControllerNameMapper

Map view-ids to bean names, using a dirSubdirPage style format.

The strategy of this mapper is as follows:

- The first character after every slash (except the first one) is converted to uppercase;
- All slashes ('/') are removed;
- All characters following the last dot ('.') are removed;
- Reserved words `RESERVED_WORDS` are prefixed with an underscore ('_');
- Resulting bean-names starting with a digit are also prefixed with an underscore.

Examples:

- "/userInfo.jsp" becomes "userInfo"
- "/SecureArea/userPassword.xhtml" becomes "secureAreaUserPassword"

Using a bean naming scheme provides the following benefits:

- The backing bean code does not need to be aware of the view path;
- The backing bean class can be in any package;
- Moving the view does not require alteration to the java code;
- There is no separate "view mapping" configuration file required with its own unique format, just normal managed-bean configuration.
- It is easy to see from the managed-bean declarations which view a bean is associated with. This information can be extremely useful when developing a large application, so a bean naming convention of this type is useful even when not being used for the purposes of view lifecycle events.

In particular, the separation between "UI designer" and "coder" remains; the UI designer can move and rearrange views without touching java code. They do need to change the bean mapping files, but that is not so significant.

The following limitations apply to this approach:

- Only one bean can be mapped to a view. However this can be worked around by providing a "relay" bean that delegates calls to all of the beans that have been injected into it.
- When a view is moved, lifecycle events will silently stop occurring if the bean-name is not been updated.
- When a view is moved, the bean-name has to change. If the bean handling viewcontroller events is also referenced by other expressions in the page, then all those expressions must also be changed. Dependency-injection configuration that uses that bean-name must also be updated. However see below for information on "bean aliasing".
- When a view is deeply nested within a directory tree, the bean name generated from the view name can become long and inconvenient to use within expressions. This is only an issue if the bean handling lifecycle events is also the target of expressions in the page, but that is often the case.

Some dependency-injection frameworks allow bean-name "aliases" to be defined, ie for a single managed-bean to have multiple names. This can be used to define one name that expressions reference the bean through, and a separate name that is used only in order to link that bean with the corresponding view. With this configuration, moving a view simply requires changing the name of the alias. If appropriate these aliases can be defined in a different configuration file from the "real" bean definitions (eg for the use of UI Designers). This approach does increase the number of managed-bean declarations required, so should only be applied where useful.

It is possible to define a very simple request-scoped bean for viewcontroller event handling that just delegates to another bean that is injected into it. This has the same effect as "bean aliasing" although it is implementable without "aliasing" support (and particularly, in plain JSF 1.1). This simple bean can be named after the view it controls, while the "real" backing bean can be named however it wishes. The same benefits and drawbacks apply as for the "aliases" approach described above.

It may be possible to also define aliases within the page definitions. In particular, for JSF the Apache Myfaces Tomahawk AliasBean can be used to define a local alias for a bean. If this is done at the top of a file, then when the view is moved, only that alias entry in the page needs to be altered rather than all expressions in the page.

Constructor Summary
`DefaultViewControllerNameMapper()`

Method Summary
`java.lang.String` | `mapViewId(java.lang.String viewId)`

Methods inherited from class java.lang.Object
`clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait`

Constructor Detail

### DefaultViewControllerNameMapper

    public DefaultViewControllerNameMapper()

Method Detail

### mapViewId

    public java.lang.String mapViewId(java.lang.String viewId)

  Specified by:
    `mapViewId` in interface `ViewControllerNameMapper`

Overview | Package | Class | Use | Tree | Deprecated | Index | Help
PREV CLASS NEXT CLASS | FRAMES NO FRAMES
SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD

Copyright © 2009 The Apache Software Foundation. All Rights Reserved.