JSF мертвий?

Технології

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 топіки правда сильно застаріли...:-(