Зачем нужен JSF, когда пользовательский интерфейс может быть реализован с помощью библиотек JavaScript, таких как jQuery и AngularJS?

Я читал о JSF, который является фреймворком пользовательского интерфейса и предоставляет некоторые компоненты пользовательского интерфейса. Но чем он лучше или отличается от количества компонентов, доступных из jQueryUI, AngularJS, ExtJS или даже простого HTML, CSS и JavaScript.

Зачем кому-то изучать JSF?

JSF для простого JSP / Servlet / HTML / CSS / JS похож на jQuery для простого JS: делайте больше с меньшим количеством кода. Чтобы взять PrimeFaces (на основе jQuery + jQuery UI) в качестве примера, просмотрите его витрину, чтобы увидеть полные примеры кода. BootsFaces (на основе jQuery + Bootstrap UI) также имеет витрину с полными примерами кода. Если вы внимательно изучите эти примеры, то увидите, что вам в основном нужен простой класс Javabean в качестве модели и файл XHTML в качестве представления.

Обратите внимание, что вы не должны рассматривать JSF как замену только HTML / CSS / JS, вы также должны учитывать серверную часть (в частности: JSP / Servlet). JSF устраняет необходимость во всем стандартном шаблоне сбора параметров HTTP-запроса, их преобразовании / проверке, обновлении значений модели, выполнении правильного метода Java для работы и генерации шаблонного кода HTML / CSS / JS. С JSF вы в основном получаете страницу XHTML в качестве определения представления и класс Javabean в качестве определения модели. Это значительно ускоряет разработку.

Как и в случае с любой компонентной веб-платформой MVC, в JSF у вас есть менее детальный контроль над визуализированным HTML / CSS / JS. Добавить собственный код JS не так просто, так как вы должны также учитывать состояние представления JSF на стороне сервера (например, включение отключенной кнопки на стороне JS не приведет к включению кнопки на стороне JSF, что, в свою очередь, огромное преимущество в безопасности). Если это, однако, серьезное препятствие, то лучше поищите веб-платформу MVC на основе действий, такую ​​как Spring MVC . Вы только примете во внимание, что вам нужно написать весь этот код HTML / CSS / JS (и предотвратить XSS, CSRF и DOM-манипуляции!) Самостоятельно . Кроме того, если вы вернетесь с Facelets на JSP, вы также упустите расширенные возможности создания шаблонов.

С другой стороны, если у вас большой веб-сайт на основе JSP / Servlet / HTML / CSS / JS / jQuery, и вы хотите реорганизовать повторяющийся шаблонный код JSP / Servlet / HTML / CSS / JS / jQuery в повторно используемые компоненты, тогда одним из решений будет JSF. В этом могут помочь пользовательские шаблоны, файлы тегов и компоненты. С этой точки зрения JSF стоит выше JSP / Servlet / HTML / CSS / JS / jQuery (и именно поэтому очень важно понять эти основы, прежде чем погружаться в JSF).

Вы можете найти настоящий стартовый проект на основе JSF здесь: Java EE Kickoff App . Вы увидите, что он содержит рядом с JSF также хорошие HTML5 , CSS3 и jQuery .

Смотрите также:

• Разница между MVC запроса и MVC компонента
• Разница между JSP, сервлетом и JSF
• Каковы основные недостатки JSF 2.0?
• Можно ли использовать JSF + Facelets с HTML 4/5?
• Когда использовать <ui: include>, файлы тегов, составные компоненты и / или пользовательские компоненты?

JSF был создан, чтобы сделать так, чтобы java-магазинам не приходилось изучать такие вещи, как jQuery, и создавать сложные JS, а вместо этого сосредотачиваться на чисто Java-стеке. В мире, где время - деньги, а множество мест уже сосредоточено на разработке Java, на один язык меньше в стеке, что ускоряет обучение и сопровождение, а значит, дешевле.

Я добавлю, что JavaScript легко превратиться в кошмар обслуживания для больших команд, особенно если некоторые из разработчиков проекта не очень разбираются в веб.

С Javascript и такими фреймворками, как jQuery, вы получаете полную гибкость и полный контроль. С ext и т.д. вы теряете контроль и должны адаптироваться к фреймворку. С JSF вы полностью теряете контроль и должны полностью адаптироваться к структуре. Вы вызываются в жизненных циклах и т. Д., И, наконец, вы не можете контролировать, когда можно сделать вызов на сервер, а где нет. Если вы собираетесь сделать что-то «особенное», вы находитесь в очень тяжелом положении. А в мире JSF даже такие базовые вещи, как сортировка многоколоночной таблицы или поля, в которые можно вводить только ограниченный набор символов (например, числовое поле), считаются «особыми».

Однако чем больше у вас гибкости, тем больше ошибок или неправильных действий вы сможете совершить. Высокая гибкость работает только с очень умными программистами, другие превратят проект в неуправляемый кошмар.

Но с JSF и его ограниченной гибкостью всегда есть только несколько (или даже только один) правильный способ что-то сделать. Вы очень ограничены, вы не можете создавать ярлыки, вы должны писать больше XML и т. Д. - но при адаптации к стандарту появляется лучший контроль над кодом, который будут создавать неопытные или неопытные программисты. В результате крупные корпорации любят JSF, потому что он «безопаснее» для них.

Когда я перешел с GWT на JSF, я был шокирован тем, как много вещей, которые были естественными для меня, считались весьма нетипичными и скольких простых вещей было так сложно достичь. Более того, даже внесение мельчайших изменений, таких как добавление знака ':' после метки, что в приложении на базе GWT / jQuery будет изменять метку, генерирующую одну функцию, потребовало изменения десятков файлов с локализованными свойствами, что даже не было рассмотрено кто-нибудь кроме меня странный ...

Преимущества использования JSF заключаются не только в создании xhtml + css + js. Иногда JSF накладывает ограничение на разметку, которую вы можете создать, как и любой компонентный фреймворк. Но JSF не только для этого, его жизненный цикл очень помогает. После проверки ввода он может без каких-либо усилий обновить модель и синхронизировать компоненты на стороне сервера. вы просто говорите: «что бы ни вводил здесь пользователь, проверьте, является ли это числом, если да, то сохраните его в свойстве YY в объекте XX», и JSF сделает все это.

Так что да, вы все равно можете использовать JQuery, JS и т. Д. Но JSF дает много преимуществ, когда дело доходит до написания кода на стороне сервера, и избавляет вас от большого количества шаблонов.

Я категорически не согласен с тем, что jsf что-либо добавляет. Это только добавляет накладные расходы. Создание пользовательского интерфейса на сервере - самая нелепая вещь, которую я когда-либо слышал. И javascript в больших командах отлично работает - это называется повторным использованием кода.

Просто оберните jquery в несколько тегов jsp, это все, что вам нужно, и все готово, и не терпите проблем с масштабируемостью и jsf и richfaces.

Поработав с JSF, Spring MVC, Struts, Grails, JQuery и ExtJS, я считаю, что Grails + ExtJS - это мощная комбинация.

В любой день я бы предпочел Grails JSF. Мне нравится полнота ExtJS как фреймворка и библиотеки на стороне клиента, но он требует более крутого обучения, чем JQuery.

Вот самые большие различия между jQuery и JSF:

• нет архитектуры MVC
• нет контроля состояния (сохранить дату в сеансе или разговоре, автоматическая очистка и т. д.)
• нет (по умолчанию) библиотеки проверки
• нет библиотеки шаблонов
• нет расширенной навигации / маршрутизации
• сторона клиента

jQuery никогда не предназначался для использования в качестве полнофункционального веб-фреймворка. Он был больше предназначен для замены низкоуровневого JS-кода, чтобы писать JS стало проще и эффективнее с меньшим количеством строк кода.

И поэтому его следует в основном использовать для добавления поведения к элементам HTML.

Пользуясь фреймворком ExtJS для большого веб-приложения, я знаю, насколько легко им пользоваться. ExtJS (Schena) лучше всего подходит для взаимодействия с базами данных (Oracle 11g) в архитектуре MVC. Представление предназначалось для визуального / пользовательского взаимодействия. Контроллер определил «обработку» и триггеры, которые необходимо было использовать для пакетов PLSQL (API для CRUD, запросы выбора SQL и т. Д.). Файлы модели и хранилища использовались для «сопоставления» элементов данных со средством просмотра / входами.

ExtJS не подходит для веб-интерфейсов, не интенсивно использующих базы данных - где Angular JS может быть лучше.