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

Ответ 1

JSF для простого JSP/Servlet/HTML/CSS/JS похож на jQuery на простой JS: делать больше с меньшим количеством кода. Чтобы взять PrimeFaces в качестве примера, просмотрите его showcase, чтобы увидеть примеры кода. RichFaces также имеет showcase с полный пример кода. Если вы внимательно изучите эти примеры, то увидите, что вам в основном нужен простой класс 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, которая, в свою очередь, огромное преимущество в плане безопасности). Если это, однако, крупный showstopper, то скорее посмотрите на основанную на действии веб-структуру MVC, например Spring MVC. Вы только учтете, что вам нужно написать весь этот код HTML/CSS/JS самостоятельно. Также, если вы вернетесь из Facelets в JSP, вы также пропустите дополнительные возможности шаблонов.

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

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

См. также:

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

Ответ 2

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

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

Ответ 3

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

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

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

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

Ответ 4

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

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

Ответ 5

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

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

Ответ 6

Работая с JSF, Spring MVC, Struts, Grails, JQuery и ExtJS, я считаю, что Grails + ExtJS - одна из мощных комбинаций.

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

Ответ 7

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

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

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

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

Ответ 8

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

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