Pull to refresh

JSF мертв?

Reading time2 min
Views29K

JSF Мертв!


Именно это я услышал когда пошел пробоваться разработчиком в одну контору. Чем занимается контора — не тема топика, достаточно знать что используют они grails. На мой вопрос «а почему не JSF?» я услышал то, что услышал. Судя по последним постам о JSF на habr — истину глаголет! Нет?!

Что в имени тебе моем?


Казалось бы, ну умер и умер, чего ленту засоряешь? Но ОНО свербит! На просторах интернетов были найдены Grails и Play! (про Spring умолчим — там и без моего скользко). В обоих набросали проектик на 5 страничек, с формочками, базовым набором контролов и навигацией — красиво. Закрыли… Открыли maven-проект с JSF 2.2.14 от 11.2016 (2.2.13 от 02.2016! МЕРТВ!?) и продолжили работать.

Проблема


В один не очень крупный проект на JSF необходимо было добавить FORM-Аутентификацию с пользователями из БД. Ничего сложного: тут пару JPA-классов, тут JSF-страничка, перечень доступных ролей в web.xml и security-constraint. СТОП! Почему так сложно?! В Grails и Play! — пара анотаций/методов и ВСЕ! Как менять web.xml если перечень ролей изменится?! Задумался… Почему все ТАК и как оно работает? Аутентификация — просто процесс сверки пары логин-пароль, дальше — разбор URL и сверка что у пользователя есть соответствующая роль. Пока все логично, но есть нюанс! Где именно происходит сверка ролей?! Ну, т.е. буквально — где ТА САМАЯ точка в коде, когда произойдет сверка ролей?

Grails, Play!, etc.


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

  1. Пользоваетль сформировал запрос
  2. По URL найден контроллер
  3. В контроллере нашли анотацию
  4. Проверили роль
  5. В контроллере подготовили модель
  6. В контроллере выбрали view
  7. Отрисовали пользователю

JavaServer Faces (JSF)


Ответ: а вам зачем? Все равно не найдете… о_О

Все потому, что в JSF обработка будет выглядеть примерно так:

  1. Пользоваетль сформировал запрос
  2. По URL найдена требуемая роль
  3. Проверили роль
  4. По URL найден контроллер (FacesServlet)
  5. Контроллер по URL нашел view
  6. По EL из view подготовили модель
  7. Отрисовали пользователю

И тут я понял, что ничего не понял.


Как сравнивать такие вещи как JSF и Play! или JSF и Grails? Они же просто разные… Если для одних — ключевой элемент это контроллер, для других — view. Одни — решают «какую страницу отрисовать?», другие решают — «что отрисовать?». Вроде полемика: «какую страницу» и «что на странице», но суть меняется кардинально. Зато понял почему GET параметры декларируются в view и почему ссылки должны быть с «faces-redirect=true».

Еще понял что для работы с произвольными ролями надо написать фильтр, и, о чудо, с анотацией WebFilter!

Послесловие


Коллеги, простите мне мою сумбурность в повествовании — пишу как общаюсь. В тексте нарочно:

  • FacesServlet назван контроллером, т.к. javabeans не более чем импортируемые к нему классы.
  • Работа с Grails и Play! была упрощена до «тезисов» и «hello world», т.к. цель показать концептуальную разницу в подходах.

А еще в JSF 2.0 «нарисовали» адекватную реализацию пользовательских тегов и Flow. Если интересно — буду рад рассказать, ибо про JSF топики правда сильно устарели… :-(
Tags:
Hubs:
-6
Comments22

Articles

Change theme settings