ВведениевJavaServerFaces (JSF).

Я специально открывал документацию по JSF. На Oracleее не ищите. Ее надо брать по EnterpriseJavaBeansцеликом. А там есть параграфы и пару больших глав по JSF. Так вот я читал эту документацию внимательно и там написано, что JSFбазируется на сервлетах. Но увидеть где там генерируются сервлеты будет еще сложнее. Но вы хотя бы знаете, как это работает. Потому что там настолько больше надстроек сверху над этими сервлетами, что увидеть и прочувствовать генерацию бессмысленно.

Далее. От чего они еще отказались? Они отказались от убогого синтаксиса JSP. Будем переучиваться.

Вот он перед вами список проблем JSP. Начнем с последней проблемы – «модель событий на сервере и их обработка». Действительно проблема! А у вас в JSPесть на сервере события? Нету. А представьте, что вы сделаете интерфейс. Допустим у вас будут checkboxesкакие-то на формочке. Пользователь выберет один. А как вы узнаете, какой он выбрал? Вам придется думать, как это все сделать. Нам нужны события, чтобы если пользователь изменил данные в каком-то поле, мы знали, что это произошло. Если он где-то переключатели поменял и т.д, мы были бы в курсе. Потому что когда придет заполненная форма (в пятый раз он уже правит ее постоянно), мы должны точно знать тут поменял и здесь поменял. И события соответственные должны подниматься на сервере. Но для того чтобы была возможность поднимать серверные события нам на сервере нужны объекты - должна быть серверная модель. А здесь что у нас? Какая, простите, серверная модель в JSP? У вас там «<jsp:useBean>» написаны, которые не имеют никакого отношения к архитектуре – у них никаких событий нет. И всё! И генерация сервлета! Какие там события? Нет там ничего. Архитектура одноэтажная. А нам надо этажей пять!

Еще момент! Что-нибудь готовое по поводу проверки пользовательского ввода. Я понимаю, что у вас есть объект requestи response. Из requestможно взять всё, что пользователь передал, но, простите, я что, каждый раз буду парсить, разбирать и все проверять? А стандартны заготовки? Данные от пользователя приходят в каком виде? Текст. А у меня double. Кто будет преобразовывать? А если у меня это не double? А другой вариант? Понимаете, да? Какая-нибудь навигация со страницы на страницу.

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

Далее… «Использование аннотаций». Это дело новое. И получается, что та технология, которую мы там использовали здесь не присутствует в явном виде. И подключение элемента (объекта класса «<jsp:useBean>») сделано в рукопашную – по-старинке на самом деле. А сегодня вспомните JavaFX, сделали аннотацию «@FXML, @FXML, @FXML, @FXML». И всё связано, все подключено. И точно такая же идея здесь на поверхности плавает. Давайте мне аннотацию, чтобы я связал свой код разметки с кодом Java. Вот это всё, включая новую архитектуру, которая позволяет делать пользовательский интерфейс и это мы все сделали в JSF.

Структура JSF приложения.

Итак, давайте смотреть. Вот эта картинка нам пригодится. Взята прямо из Enterpriseдокументации. Здесь показано, через какую обработку проходит клиентский запрос вот в этой технологии. В JSPмы видели: «генерируется сервлет, потом раз-два, кэшируется и ответ клиенту». В JSFвсе совсем другое. Тут абсолютно другой движок. Давайте по шагам.

Зеленым цветом обозначены «шаги», а синим цветом обозначены «срабатывающие события» - это как следствие зеленого цвета.

· Вот пришел клиентский запрос на сервер.

· «RestoreView» - Сервер видя к какой страничке JSFидет обращение, он её загружает в оперативную память. Но каждый раз повторно это делать не хочется. Поэтому они один раз загружают при первом обращении. Они всё распарсят, они всё что нужно сделают, они всё что нужно сгенерируют и вот это сохранят. И вот это у них называется «View», а по сути – это дерево объектов. Вот если это дерево объектов существует, они его находят и загружают все дочерние и родительские элементы. Всё в этом дереве есть.

· «ApplyRequests» - в клинтском запросе была заполнена формочка на клиенском браузере. В этой формочке 50 полей. Вот эти 50 порций данных раскидываются по объектам дерева. Вот это и есть ApplyRequests. Откуда мы знаем, что из этой формочки и из этого поля? А это мы увидим чуть позже. Все должно быть проще и очевиднее. У вас дерево объектов – это и есть HTML. В формах заполнения есть id? Есть.

· Пользовательские данные, которые в эти элементы были помещены, они дальше должны перейти в ваши Javaклассы. Но это после проверки только можно сделать. Поэтому следующее «срабатывание проверок». Вы можете написать свои проверки, а можете использовать стандартные проверки. Если что-то там некорректно, что-то было незаполнено или не устраивает тип данных – не важно – то происходит событие. Видите стрелочка куда-то пошла. Если что-то незаполнено, то эта же формочка с сообщениями об ошибках возвращается клиенту. Т.е. вся остальная цепочка обработки обрывается. Незаполнил поле? Error. И ему все обратно кидаюти говорят ему: «вот тут незаполнено». Если прошли через этот этап, то попадаем на этап обновления данных, но это уже в модели. Это ваш бизнес-объект на Java и данные из дерева объектов перекладываются в бизнес-объект. При этом при перекладывании тоже происходит определенное преобразование. Там может произойти какой-то преобразование типов и т.д. Здесь могут быть какие-то события и какие-то ошибки вот этого преобразования и тогда снова мы вылетаем. Если вы добрались до последнего, то это срабатывание тех событий, которые в этой серверной модели предусмотрены. Допустим изменение надписи. Какой-то checkboxбыл отмечен, клик на кнопку и т.д. Вы на эти события вешаете свои обработчики, они в этом наборе срабатывают и уже полученный результат отправляется клиенту. Так что клиент либо получит error, либо получит какое-то подтверждение сохраненных данных. Вот эти стрелочки, которые трижды здесь сделаны, дело в том, что то, что у нас происходит на любом этапе, в любом из ваших обработчиков можно взять и сказать: «Неа, вообще хочу дать ему из google.rowкакую-нибудь страничку». Т.е. тут можно перекинуть куда угодно. Т.е. можно все отменить и сказать: «всё, хорош». Давай ему вот это вернем и он будет счастлив. Такая возможность прервать называется «ResponseComplete».

Вот это и называется конвеер обработки или жизненный цикл.

Идея понятна? Вы видите, что по сути половина того, что здесь хотелось сделать, в этом жизненном цикле предусмотрена явно. А иначе никак. А как ты реализуешь события, если у тебя и объектов нет?

А вы вообще представляете, как вообще может возникнуть событие, что текст изменился? Вот я отправил формочку. Там написано «имя» и «фамилия» автора книги. Он посмотрел и видит, что в авторе где-то там ошибка, он поменял одно слово, нажал кнопочку Submit и данные пошли обратно на сервер. Как мы узнаем, что он изменил фамилию?

Ответ: «управление состоянием» это часть этой инфраструктуры. Смотрите, что делается. Прежде чем отправлять данные клиенту, мы эти данные у себя фиксируем и запоминаем их. А когда приходит ответ, у нас в формочке есть новые данные. И мы их сравниваем.

Ответ из зала: Так это же долго!

Ответ препода: А кто говорил, что это летает? Никто не говорил. Посмотрите, какой здесь цикл обработки! Ну конечно долго! А как вы хотели? Да! Долго! Но какие сегодня по мощности машины несравнимые с тем, что было раньше, когда вы загружали отдельную страничку! А если бы вы видели, как у Microsoftв ASP.NETвсе собирается? Там еще больше этапов. Хотите сервисы? Платите за это.

Но когда мы отправим простейший вариант клиенту (например, сгенерированная страничка в заготовке проекта) уже там мы увидим, что будет дополнительное поле hidden-fieldв htmlна клиенте, где записан некий идентификатор состояния. Потом когда придет обратный ответ, мы этот идентификатор состояния вынем, найдем наши данные и начнем… Вы думаете это по хэш-коду они сравнивают изменилось или нет? Мы должны знать конкретно, какая текстовая запись изменилась. Потому что хэш-код вам даст только информацию, что что-то изменилось, а потом она сравнивает все поля, чтобы сказать событие должно быть на этом текстовом поле, потому что в нем изменился текст.

Итак, дальше нам нужно сделать только одно. Открываем этот слайд. Но детально разбирать его мы будем завтра на свежую голову.