После конвертера кто должен работать?

Ответ: Проверка значений. Потому что если вы преобразовали в число, то что ввел пользователь, это было удачное преобразование. То следующий проверяет диапазон значений, может быть я отрицательный год ввел. Или трехтысячный. Поэтому следующим должен идти вариант, который занимается проверкой данных.

Прежде чем пойти на перерыв, будем свой конвертер писать или вот этого кода достаточно, чтобы его Copy-Pasteсделать. Мы как-то раз делали конвертер. Знаете, что он вытворял? У нас был возраст. А он преобразовывал его в типы «юноша», «мальчик», «мужчина» в зависимости от возраста.

После перерыва посмотрим «проверку данных»

validateDoubleRange validateLength validateLongRange validateRegex validateRequired

 

Итак, данные отконвертированы, потом их проверяем. Кстати, вот они регулярные выражения. Но естенственно есть и готовые проверки, потому что все писать руками было бы с т.з. современного подхода – не правильно. Смотрите, что может проверить для вас в готовом виде класс, который вы подключаете.

· диапазон – long, double

У нас есть возможность проверить длину строки, наличие параметра required–это самый простой наверно вариант. Есть еще готовая и вполне развернутая проверка – это на базе регулярных выражений.

Итак, у нас есть какое-то поле и внутри этого поля делается тег «< f:».

Кстати, интересно, что диапазоны значений могут быть взяты из членов класса.

Обязательно здесь нигде не показано, но это самое простое. Если вы хотите сделать поле обязательным для заполнения, то добавляете в inputTextновый параметр «required= true».

А если надо сделать что-то посложнее, то тогда пишется <f:validateRegex>и паттерн, который вы здесь видите, например, возможность проверить пароль. Помните этот неприятный момент? «Введите сильный пароль»!

И как только вы говорите: «Ну замечательно, конечно. Это все хорошо! Но наши бизнес-требования не можем мы реализовать с помощью этого.» Пожалуйста! Всё точно также как и в конвертерах.

Вы пишете свою проверку. Своя проверка – это метод. Это не класс, а метод. В классе Clientу вас есть возможность подключить проверку – специальное поле – в настройках объекта Validatorи там указываете именно методы, которые будут вызываться для проверки этого поля. Метод показан сверху. Учтите, что вы пишете его не как хотите, там параметры фиксированные:

· FacesContext context – контекст

· UICompinenttoValidate – объект в котором это значение проверяется

· Objectvalue – это то значение, которое указал пользователь и которое вы будете проверять

Если оказалось, что проверка не пройдена, то вы должны установить в этом объекте, который мы проверяем toValidate, что он не прошел проверку, setValid(false), а это же Runtime–это же ваша проверка, вы можете своё собственное сообщение сформировать. Ествественно создается объект FacesMessage, а потом вы его добавляете в контекст.

Так что если вы хотите проверить что-то свое нестандартное, то ради Бога! Это всегда можно сделать. Ну а мы поставим какую-то проверку по диапазону. Я поставил required – это раз. Я здесь сейчас уберу закрывающий тег. Почему? А мне двойной нужен. Эти все элементы, которые мы разбираем, они идут как подэлементы. Что мы хотели сделать? Давайте сделаем range.

Способов подписки, на любое из событий, всего два: - передача имени обработчика в атрибут <h: элемента; - передача имени класса, реализующего служебный интерфейс, в атрибут <f: элемента.

Последний шаг, после которого должна быть лаба. Мы сейчас должны посмотреть одну из самых важных тем. Это, конечно, все хорошо – конвертеры, проверки. Это нужно. Это правильно. Но по большому счету – это вся история с жизненным циклом, она, конечно, затевалась для чего? Чтобы вы могли сделать культурно у себя в программе на сервере обработку на какие-то действительно важные для вас события и изменения, которые происходят в клиентской форме. Как это можно сделать, если у HTML-элементов серверного вообще ничего нету? Если я буду на сервере писать HTML, значит опять ничего нет на сервере. И вот здесь становится понятно, что обойтись без их собственных объектов, которые мы используем («<h:>»)было бы невозможно.

Итак! Обратите внимание, что у нас события. Всего у нас событий есть:

· valuechangeevents – изменения, сделанные пользователем

· actionevents – нажали на какую-то кнопку.

· Applicationevents – события жизненного цикла JSF

Поэтому обработка этих событий чуть-чуть разнится, но 1 и 2 очень похожи. Именилось что-то. А что может измениться?

Выбор в списке может измениться. Надпись может измениться. Как только вы увидите где-нибудь возможность в качестве артибутов у какого-то элемента управления использовать ValueChangeListener–это вам подсказка, что здесь есть возможность написать обработчик на изменение параметра. У inputTextесть параметр valueChangeListener. Итак, у нас есть какой-то элемент который модифицируется на формочке у клиента и у него вы добавляете valueChangeListener. Что там пишется? Ваш обработчик.

Как написать обработчик? Существует два способа:

Вариант первый: Это обычный метод (член класса). Я беру класс clientи добавляю еще один метод. Правда он с фиксированным параметром. Видите? У него ValueChangeEvent. Где вы из этого event-объектавынимаете getNewValueи вы там сами решаете, что с ним делать.

Вариант второй: Вы делаете обработчик, как отдельный класс. Соответственно, вы реализуете служебный интерфейс ValueChangeListener. Параметры у этого класса, соответствуют тому, чтобы вы писали в классе. Метод, конечно, стандартный из интерфейса, но параметр тот же самый - ValueChangeEvent.

Но когда вы подписываете объект, как обработку событий, то надо делать ValueChang eListener в виде отдельного параметра. Там есть typeчтобы инфраструктура понимала объект какого класса нужно создавать, чтобы получить обработчик событий. В typeвы пишете полное имя – пакет.имя_класса. Сложно? Вроде ничего.

Кнопочку кликаем – ActionEvent. Какой-нибудь link кликаем – опять же ActionEvent. Для нас способом увидеть это событие – это атрибут ActionListener.

На кнопочке что-то написано, что должно произойти когда на эту кнопочку кликнем. Ну во-первых, все данные отправляются на сервер – это понятно. Но там вы тоже хотите поучаствовать в обработке. Мало ли какие у вас там бизнес-задачи? Пользователь что-то там кликнул, ему что-то дали, «сохранить». Ну это же ваш код должен сохранять данные в БД. То, что инфраструктура переложила информацию из полей формочки в объект-клиент – это хорошо. А все оставшиеся действия вы в этом обработчике будете писать,как кто сохраняет в БД.

И опять вариантов снова два:

Вариант первый: Вверху вы используете атрибут ActionListenerгде пишете метод с помощью вот этого выражения. С помощью этого языка ExpressionLanguage. И прототип этого метода показан сверху. Этот метод возвращает void. А параметр – ActionEvent.

Вариант второй: Внова через реализацию интерфейса. И всё то же самое. Вам придется указать для этого объекта тег с полным именем класса, который является обработчиком на события. Второй метод предпочтителен, если вы написали один обработчик, а он потом в разных местах используется, то это универсальная бизнес-логика.

Ну и последний вариант:

PostConstructApplicationEvent               PreDestroyApplicationEvent     PreRenderViewEvent

 

В целом есть приложения-события. Их мало – всего 3.

У нас есть «PostConstructApplicationEvent» - это когда самый первый пользователь обратился к вашему приложению WebApplicationи в какой-то момент, когда это все начинает подниматься, и срабатывает данное событие. Вдруг вам надо что-то важное сделать для всего приложения в целом? Какие-то данные в какие-то объекты закачать и т.д.

Ну а соответственно, если вы дополнительные ресурсы при запуске приложения потребовали, то вы их освобождаете в «PreDestroyApplicationEvent». И, при обработке каждой страницы, оно здесь называется «PreRenderViewEvent» - вы подготовили все данные, все сделали, все ваши обработчики сработали и следующим шагом должно быть рендеринг и отправка клиенту. Поэтому последняя возможность вмешаться и что-то поменять – это вот это событие. Вы вносите какие-то изменения и корректировки и уже дальше это дерево объектов теперь рендерится и результат отправляется клиенту. Ну в целом разумно. А может быть я захочу какой-нибудь JavaScriptили HTMLдобавить с потолка? Это будет ваш вариант «PreRenderViewEvent». Как это сделать?

Значит PreRenderViewEvent размещается на страничке. Страничка связана с бизнес-объектом. Значит мы можем этот бизнес-объект поместить в метод, который имеет компонент SystemEvent. И тем самым вы сможете для конкретного компонента на странице можно сделать PreRenderViewEvent для всей формы.

А вот второй вариант: Это событие связано с приложением в целом. Ну понятно, что на какой-то конкретной страничке странно бы выглядело подписчик на эти события. Это все делается в конфигурационном файле. Вот перед вами некий кусок конфигурационного файла. SystemEventListener, что мы собираемся слушать события PostConstructApplicationEventи здесь прописывается какой класс отвечает. Ну этот класс вам придется написать. Поэтому второй пункт ведет себя как реализация некоторого служебного интерфейса.

Давайте попробуем сделать обработку – изменилось значение? И вот затронуть ApplicationEventsхотелось бы тоже.

ДавайтеначнемсApplicationEvents.

Копируем это в нашу формочку:

Соответственно мне в классе Clientнужно реализовать метод handleEvent.

Итак! Что у нас получилось? Мы добавили обработку на события preRenderViewи класс Clientдобювляем этот метод. Понятно, что вся бизнес-логика в этом методе сведется к System.out.println(…), которая позволит написать:

Ну это надо попробовать. Жмем F6. Смотрите. Конечно же за это время все быстро отрендерилось, но мы можем посмотреть в консоль GlassFish, и что мы увидим? А вот что.

Видите? А потом вызвался гетер. Т.е. как происходит рендеринг? Они должны взять дерево объектов, а в дереве объектов гетеры считывают значение – выполняют этот важный expressionlanguage. Но наш рендер работает до expressionlanguage. Поэтому если вы в ваших объектах внутри класса поменяете данные, то вы этого не измените.

Ну, конечно же, это все баловство. Я думаю вы это понимаете. Самым основным для нас событием является valuechangeevents.

И здесь должен быть указан метод, который отвечает за обработку. Если метода пока нет, то, конечно, вы его просто пишете. Этот метод будет вызываться на сервере, если клиент изменит его. Вариант, как написать обработку, т.е. как реализовать этот метод конечно лучше взять со слайда №23.