Пример использования аннотации управления в классе выглядит следующим образом:

@ManagedBean

@SessionScoped

public class DukesBday{

...

}

Вышеуказанный фрагмент кода создает бин, который управляется сервером

JavaServer Faces и доступен на протяжении сеанса работы приложения. Вам не нуж-

но конфигурировать managed-bean в файле faces-config.xml. Таким образом, аннота-

ции облегчают задачу конфигурации управления бином, значительно сокращая объем кода приложения.

Вы можете также определить область видимости бина внутри файла класса,

как показано в примере выше. Это средство пригодно для бина с объявленной обла-

стью видимости request, session или application , но не областью view.

Все аннотации классов будут сканироваться при запуске приложения. Если в файле faces-config.xml не указан элемент <faces-config>, то будет установлен атрибут

<metadata-complete> в true.

Аннотации также доступны для других артефактов, как например, компоненты,

преобразователи, проверки и генераторы кода для использования вместо их описания

в файлах конфигурации приложения.

9.5. Регистрация сообщений об ошибках как пакет ресурса

Если вы создаете пользовательские сообщения об ошибках (которые отображаются тегами message и messages) для ваших преобразователей или проверок, нужно

сделать их доступными во время запуска приложения. Это делается одним из двух

способов: организацией очереди сообщений в экземпляре FacesContext программно или регистрацией сообщения с использованием файла конфигурации приложения.

Пример регистрации сообщения для приложения:

<application> <message-bundle>

com.sun.bookstore6.resources.ApplicationMessages </message-bundle>

<locale-config> <default-locale>en</default-locale> <supported-locale>es</supported-locale> <supported-locale>de</supported-locale> <supported-locale>ru</supported-locale>

</locale-config> </application>

Этот набор элементов позволит вашему приложению использовать сообщения,

которые содержатся в сответствующем пакете ресурсов.

Элемент message-bundle представляет набор локализованных сообщений. Он

должен содержать полный путь в пакет ресурсов, содержащий локализованные со-

общения (в данном случае resources.ApplicationMessages).

97

Элемент locale-config включает языковый регион по умолчанию и другие возможные регионы. Он позволяет системе находить правильный регион, основанный на

установках языковых параметров в браузере клиента.

Теги supported-locale и default-locale принимают двухсимвольный код на ниж-

нем регистре, определённый в рекомендации ISO 639 (см. http://www.ics.uci.edu/pub/ ietf/http/related/iso639.txt). Убедитесь, что ваш пакет ресурса действительно содержит сообщения для локальных зон, которые вы определяете этими тегами. Чтобы иметь

доступ к локализованному сообщению, прикладной разработчик просто ссылается на

код сообщения из пакета ресурсов.

Регистрация локализованного статического текста (Custom Localized StaticText)

Чтобы иметь доступ к тексту, любой локализованный статический текст, который не загружается на страницу с использованием тега loadBundle, должен быть зареги-

стрирован приложением с помощью элемента resource-bundle в файле конфигурации

приложения. Аналогичным образом любые ваши сообщения об ошибках, на которые

ссылаются атрибуты converterMessage, requiredMessage или validatorMessage тега

компонента ввода, должны также быть доступными для приложения посредством тега loadBundle или элемента resource-bundle файла конфигурации.

Вот часть файла, который регистрирует несколько сообщений об ошибках для

приложения guessNumber:

<application>

...

<resource-bundle> <base-name>

guessNumber.ApplicationMessages </base-name> <var>customMessages</var>

</resource-bundle>

...

</application>

Аналогично для тега loadBundle значение подэлемента base-name определяет

полное имя класса ResourceBundle, расположенного в пакете ресурсов приложения. Таким же образом в атрибуте var тега loadBundle подэлемент var элемента resourcebundle является псевдонимом для класса ResourceBundle. Этот псевдоним использу-

ется тегами на странице, чтобы идентифицировать пакет ресурса.

Элемент locale-config, описанный в п. 9.4.4, также относится к сообщениям, а

статический текст идентифицируется элементом resource-bundle. Как и в случае иден-

тификации пакета ресурсов элементом message-bundle, убедитесь, что пакет ресурса, идентифицированный элементом resource-bundle, действительно содержит сообще-

ния для локальных зон, которые вы определяете элементом locale-config.

9.6. Проверка по умолчанию

(Default Validator)

Дополнительно к проверкам, которые вы объявляете в компонентах пользовательского интерфейса (UI), можно также определить ноль или более проверок по

умолчанию в файле конфигурации приложения. Проверка по умолчанию относится ко всем экземплярам UIInput вида или компонентного дерева и добавляется после опре-

98

<to-view-id>/storefront.jsp</to-view-id> </navigation-case>

<navigation-case> <from-action>#{LogonForm.logon}</from-action> <from-outcome>failure</from-outcome> <to-view-id>/logon.jsp</to-view-id>

</navigation-case> </navigation-rule>

Эти правила навигации определяют возможные пути перехода из страницы logon.jsp. Каждый элемент navigation-case определяет один возможный путь перехода

из logon.jsp. Первый navigation-case сообщает: если метод LogonForm.logon возвращает

результат success, то доступна страница storefront.jsp. Второй navigation-case сообщает,

что нужно перейти к logon.jsp, если метод бина LogonForm.logon возвратит failure.

Каждый элемент правила навигации navigation-rule соответствует одной странице компонентного дерева, определённого дополнительным элементом from-view-id.

Это означает, что при наличии from-view-id каждое правило определяет возможные

пути перехода для одной конкретной страницы приложения. Если нет элемента from- view-id, то правила навигации, определённые элементом navigation-rule, относятся ко

всем страницам в приложении. Элемент navigation-rule также допускает шаблоны. В

следующем примере элемент from-view-id сообщает, что правила навигации применимы ко всем страницам в директории books:

<from-view-id>/books/*</from-view-id>

Как показано в примере правила навигации, элемент navigation-rule может содержать нуль или более элементов navigation-case. Элемент navigation-case определяет набор критериев сопоставления. Когда эти критерии выполняются, приложение будет переходить на страницу, определённую элементом to-view-id, содержащимся в

том же элементе navigation-case.

Критерии навигации определены дополнительными элементами from-outcome и from-action. Элемент from-outcome определяет логический результат, например, success. Элемент from-action использует выражение-метод, чтобы ссылаться на метод действия, который возвращает строку – логический результат. Метод выполняет

некоторую логику, чтобы вычислить и возвратить результат.

Элементы navigation-case сверяются с результатом или выражением-методом в

следующем порядке:

•если определены оба значения from-outcome и from-action, то оба эти эле-

мента могут быть использованы в том случае, если метод action возвращает

разные результаты в зависимости от выполняемой обработки;

•если определено только значение from-outcome, то элемент должен соответствовать результату, определённому атрибутом действия компонента

UICommand или результату метода, указанного компонентом UICommand;

•если определено только значение from-action, то значение должно соответствовать выражению action, определённому тегом компонента.

Когда встречается любой из этих вариантов, компонентное дерево, определённое элементом to-view-id, будет выбрано для показа.

Используя NetBeans IDE, вы можете сконфигурировать правила навигации сле-

дующим образом.

1.После открытия вашего проекта в NetBeans IDE раскройте узел проекта в подокне проектов.

100