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.
Ответ: где анотация, там и сверят. Если очень грубо, обработка запроса будет выглядет так:
- Пользоваетль сформировал запрос
- По URL найден контроллер
- В контроллере нашли анотацию
- Проверили роль
- В контроллере подготовили модель
- В контроллере выбрали view
- Отрисовали пользователю
JavaServer Faces (JSF)
Ответ: а вам зачем? Все равно не найдете… о_О
Все потому, что в JSF обработка будет выглядеть примерно так:
- Пользоваетль сформировал запрос
- По URL найдена требуемая роль
- Проверили роль
- По URL найден контроллер (FacesServlet)
- Контроллер по URL нашел view
- По EL из view подготовили модель
- Отрисовали пользователю
И тут я понял, что ничего не понял.
Как сравнивать такие вещи как JSF и Play! или JSF и Grails? Они же просто разные… Если для одних — ключевой элемент это контроллер, для других — view. Одни — решают «какую страницу отрисовать?», другие решают — «что отрисовать?». Вроде полемика: «какую страницу» и «что на странице», но суть меняется кардинально. Зато понял почему GET параметры декларируются в view и почему ссылки должны быть с «faces-redirect=true».
Еще понял что для работы с произвольными ролями надо написать фильтр, и, о чудо, с анотацией WebFilter!
Послесловие
Коллеги, простите мне мою сумбурность в повествовании — пишу как общаюсь. В тексте нарочно:
- FacesServlet назван контроллером, т.к. javabeans не более чем импортируемые к нему классы.
- Работа с Grails и Play! была упрощена до «тезисов» и «hello world», т.к. цель показать концептуальную разницу в подходах.
А еще в JSF 2.0 «нарисовали» адекватную реализацию пользовательских тегов и Flow. Если интересно — буду рад рассказать, ибо про JSF топики правда сильно устарели… :-(
Комментарии (18)
AndreyRubankov
23.11.2016 08:59+2Вас обидели тем, что технология, на которую вы потратили полжизни теперь никому не нужна? Вы хотите поговорить об этом? Хабра — это не то место, куда вам нужно идти!
metej
23.11.2016 12:56-1Обида тут совершенно не при чем.
Ожидал услышать что «JSF мертворожденный», «тормозной», «не гибкий из-за xml» и прочие болезни JSF 1.2, а услышал «да от него все отказались, а мы даже и пробовать не стали». о_О
Это от человека работающего в grails (основной костяк реализован на groovy, а он и сам не так давно был в подвешенном состоянии)!
Т.е. предметного разговора не получилось. Просто «он мертв». Все. Без альтернатив.
Опять же, вместо пустых разговоров я не поленился перепроверить мнение. Какие уж тут обиды?AndreyRubankov
23.11.2016 14:07Все просто. Ваш пост очень похож на крик души. Вы не рассказали как на jsf создавать сайты, не показали, как это быстро, не показали ни одного примера успешной компании, которая использует jsf и главное Будет использовать его в новых проектах. Вместо этого ваш текст содержал некую насмешку и удивление тем, что кто-то считает grails живее jsf.
Думаю, большинство заходящих в топик ожидали увидеть более ценную информацию. Увидеть сравнение с другими технологиями или на худой конец информацию о том, как он развивается, что нового планируется в версии 2.3.metej
23.11.2016 14:12Будет. Будет про 2.2, т.к. актуальная, т.к. по сравнению с 1.2 сильно лучше.
Честно-честно будет.
officeMouse
23.11.2016 09:37-3Чаще всего «красивые» статьи и блоги пишут люди которые особо не разбираются в теме. Рассуждать про технологию мертва она или нет можно сколько угодно, НО существует конторы которые разрабатывают и поддерживают JSF контролы и благополучно их продают… При этом «чудо» технологии появляются и через год — два про них все забывают… Если разрабатываешь на «коленке» страничку для ИП то используй, что угодно. Если пишешь приложение уровня предприятия, то и используй стабильную технологию т.к. ее после поддерживать просто кому угодно…
LincolnFaradey
23.11.2016 11:22Работаю в Nuxeo, когда то давно переписали платформу с питона на православную Java, было это, этак лет 7 назад и уже тогда были отзывы о JSF, как о мертворожденной технологии/фреймфорке. Но ничего, ребята у нас хорошие, все сделали здраво, все работает и по сей день и вот мы релизим 8 версию нашей платформы, где все наши аддоны тянут зависимости в соответствии с наличием или отсутствием JSF, так как по дефолту мы отказались от данной технологии и поставляем голый сервер с рекомендации установить WebUI (Polymer под капотом), конечно же при желании можно поставить старый UI и наслаждаться привычным интерфейсом.
У вас конечно же вопрос, а зачем, масштабный проект, да переводить на относительно сырой фрейм?
Да все просто: производительность, модульность, да и написано по человечески.
Для примера, время холодного старта упало с 24 до 2 секунд. Можно конечно сказать что руки у нас ни из того места, но столько лет и такие руки — расти не могут. :)metej
23.11.2016 13:05-1Мне тут как-то довелось проверить скорость рендеринга формы и таблички из БД на twisted+slqalchemy, tornado+slqalchemy и jsf+hibernate.
Результаты удивили: twisted и tornado рисовали страничку за 16-18 мс., jsf управился за 4-6 мс!
Грешил на БД и/или ORM. Убрал их как явление и отрисовывал данные из json файла. Py-like: 6-8 мс, JSF: 2-4 мс.
Много думал…
metej
23.11.2016 11:28Парадоксальные вещи творятся в сообществе — технология вроде мертва, но…
Меньше чем за сутки топик просмотрели без малого 2к раз! Т.е. она мертва, но не мертва.
Без обиняков — чую придется еще пару раз приложиться к черновику, и, таки написать о минимальном проекте на maven+JSF. Так обсуждение будет более предметным.
По теме — коллеги, боюсь большинство сталкивалось с JSF версии 1.2.
Так вот 1.2 — действительно мрак, сам плевался и пришел к выводу что JSP мне хватит «за глаза».
Но вот уже 2.2 — очень даже сильна и приятна в использовании. Рекомендую!
playermet
23.11.2016 14:18> Меньше чем за сутки топик просмотрели без малого 2к раз! Т.е. она мертва, но не мертва.
Число просмотревших топик не равно числу использующих JSF. Я например просто кликнул на интересный заголовок, до того даже не знал что это.
Fedcomp
23.11.2016 11:34+1> Меньше чем за сутки топик просмотрели без малого 2к раз
Абсолютно ни о чем не говорит. Многие кто просматривает — случайные проходящие.
gkislin
23.11.2016 13:43Я вот не случайно прошел- мне интересно — жива или нет, хоть с JSF и не работал. И минусить всех, кто с ней работал и что-то может про нее реальное сказать мне кажется проявлением стадности.
shishmakov
23.11.2016 14:33Никогда не писал на JSF 1.2 и сразу на JSF 2.x = Facelets, CDI, Life Cycle + Custom Beans (Validators)…
Всё вроде бы нормально. Но нормально для серверных программистов.
Если вы UIщик, то вам не будет хватать компонентов и вы начнёте искать дополнительные библиотеки (RichFaces и прочее), которые имеют свой собственный Look and Feel, они будут работать и выглядеть не так как хочется вам… А ещё этот рендер на стороне сервера.
Потом вы будете смотреть на Vaadin и думать переходить ли на него.
Поэтому JSF он не для всех, кому-то нужно проще и быстрее, и легче, а кому-то лучшего и не надо.
ИМХО JSF хорошо подходит для написание web-админки, даже очень разухабистой админки.metej
23.11.2016 15:41Для разного рода JS на клиенте есть такое: https://javaserverfaces.java.net/docs/2.3/jsdocs/
Это JavaScript библиотека отправляемая на клиентскую сторону.
С ее помощью можно дергать элементы JSF страницы из js.
В остальном — для клиентской отрисовки нужен REST, а это не сюда… скорее к JAX-RS.
На странице вполне может быть контент генерируемый сервером и блок div с id в который JS отрисует свои контролы.shishmakov
23.11.2016 15:43Спасибо, я правильно понимаю, что это в JSF 2.3 только?
metej
23.11.2016 15:53Нет, в JSF 2.2 тоже живет: https://javaserverfaces.java.net/docs/2.2/jsdocs/
Обратите внимание на «jsf.ajax.request»
А тут от IBM чтиво: http://www.ibm.com/developerworks/ru/library/j-jsf2fu-0410/index.html
grossws
23.11.2016 17:58Как сейчас у jsf с разваливанием состояния при протухании пользовательской сессии?
metej
24.11.2016 06:27Если речь про корректное завершение транзакций/закрытие соединений и пр. в бинах — работают аннотации PostConstruct и PreDestroy.
Если нет — прошу уточнить вопрос, т.к. по идее у протухших сессий и и должен разваливаться State.
JSF уже часть JEE6, т.е. http://docs.oracle.com/javaee/6/tutorial/doc/gmgkd.html верна и для JSF.
jbubsk
Ну что уж тут говорить, он мёртв. И никакие угодники его уже не воскресят. Да и ни к чему это.