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

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

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

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

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

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

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

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

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

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

Просто оберните jquery в некоторые теги jsp, вот и все, что вам нужно, и вы сделали это, и не переносите проблемы .sackles и масштабируемости с .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 (Oracle 11g) в архитектуре MVC. Представление предназначалось для визуальных/пользовательских взаимодействий. Контроллер указал "обработку" и триггеры, которые необходимо использовать, из пакетов PLSQL (API для запросов CRUD, SQL select и т.д.). Модель и файлы хранилища использовались для "отображения" элементов данных в Viewer/input.

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