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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

и поэтому он должен в основном использоваться для добавления поведения на HTML-элементы.

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

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