Каковы основные недостатки Java Server Faces 2.0?

после 5 лет работы с JSF я думаю, что могу добавить свои 2 цента.

два крупный в JSF недостатки:

1. большой кривой обучения. JSF сложный, это правда.
2. его компонент природа. Компонентная структура пытается скрыть истинную природу Интернета, которая поставляется с огромным количеством осложнений и катастроф (например, не поддерживает GET в JSF в течение почти 5 лет).
   ИМХО скрывает HTTP Запрос / ответ от разработчика-огромная ошибка. По моему опыту, каждая компонентная структура добавляет абстракцию в веб-разработку, и эта абстракция приводит к ненужным накладным расходам и более высокой сложности.

и несовершеннолетний недостатки, которые приходят мне в голову:

1. по умолчанию ID объекта состоит из идентификаторов его родителей, например form1:button1.
2. нет простого способа прокомментировать неправильную страницу фрагмент. Tag <ui:remove> нуждается в синтаксически правильном содержании, которое все равно анализируется.
3. низкое качество сторонних компонентов, которые, например, не проверяют isRendered() внутри processXxx() метод, прежде чем продолжить.
4. включение меньше & Sencha трудно.
5. не играет хорошо с отдыхом.
6. не так просто для дизайнеров UX, потому что готовые к использованию компоненты имеют свои собственные стили CSS, которые необходимо перезаписать.

не вам я ошибаюсь. Как компонентная структура JSF в версии 2 действительно хороша, но она по-прежнему основана на компонентах и всегда будет...

обратите внимание на низкую популярность гобелена, калитки и низкий энтузиазм опытных разработчиков JSF (что еще более значимо). И для контраста взгляните на успех Rails, Grails, Django, Play! Фреймворк-все они основаны на действиях и не пытаются скрыться от программиста истинный запрос/ответ и без гражданства природа!--7--> веб.

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

надеюсь, что это поможет кому-то с его / ее выбором, который касается front-end.

несколько недостатков, которые приходят на ум:

1. JSF-это компонент основы. Это неотъемлемые ограничения, которые иметь дело с повиновением компонентная модель.
2. AFAIK JSF поддерживает только сообщение, поэтому, если вы хотите получить где-то у вас есть сделать простой сервлет / JSP.
3. большинство компонентов пытаются предоставить абстракции над доменами, такими как реляционные базы данных и интерфейсных JavaScript, и много раз эти абстракции "протекают" и очень трудно отлаживать.
4. эти абстракции могут быть хорошей отправной точкой для младшего разработчика или кого-то, кому не комфортно с определенным доменом (например, front-end JavaScript), но их очень трудно оптимизировать для производительности, поскольку есть несколько уровней, и большинство людей, которые их используют, мало понимают, что происходит под капотом.
5. шаблонизатор механизмы, которые обычно используются с JSF не имеют ничего общего с тем, как веб-desigers работы. редактор WYSIWYG для JSF примитивны и в любом случае, ваш дизайнер даст вам HTML/CSS, который вам придется потратить века преобразования.
6. такие вещи, как выражения EL, не проверяются статически, и компилятор и IDEs не выполняют хорошую работу по поиску ошибок, поэтому вы получите ошибки, которые вам придется ловить во время выполнения. Это может быть хорошо для динамически типизированного языка, такого как Ruby или PHP, но если мне нужно противостоять явному раздуванию экосистемы Java, я требую ввода для моего шаблоны.

подведем итоги: время, которое вы сэкономите с помощью JSF, избегая писать код JSP/servlet / bean boilerplate, вы потратите его x10, чтобы сделать его масштабируемым и делать именно то, что вы хотите.

для меня самым большим недостатком JSF 2.0 является кривая обучения не только JSF, но и библиотек компонентов, которые вы должны использовать, чтобы заставить его выполнять полезную работу. Рассмотрим ошеломляющее количество спецификаций и стандартов, с которыми вы имеете дело, чтобы действительно быть опытным:

• HTML в различных воплощениях. Не притворяйся, что тебе не нужно это знать.
• HTTP -- когда вы не можете понять, что происходит, вы должны открыть Firebug и посмотреть. Для что тебе нужно это знать.
• CSS -- нравится это или нет. Это не так уж плохо, и есть некоторые хорошие инструменты, по крайней мере.
• XML -- JSF, вероятно, будет первым местом, где вы используете пространства имен в этой степени.
• Спецификация Сервлетов. Рано или поздно вы попадете в методы вызова в этом пакете. Кроме того, вы должны знать, как ваши Facelets превращается в XHTML или что-то еще.
• JSP (в основном, чтобы вы знали, почему вам это не нужно В JSF)
• JSTL (опять же, в основном, чтобы справиться с устаревшей структурой)
• язык выражений (El) в его различных формах.
• ECMAScript, JavaScript или как вы еще хотите это назвать.
• в формате JSON, вы должны знать это, даже если вы не используете его.
• "Аякса". Я бы сказал, что JSF 2.0 делает достойную работу, скрывая это от вас, но вам все равно нужно знать, что происходит.
• дом. И как браузер использует его. Видеть В ECMAScript.
• DOM события -- тема сама по себе.
• Java Persistence Architecture (JPA), если вы хотите, чтобы ваше приложение имело какую-либо базу данных back end.
• сама Java.
• JSEE, пока вы на нем.
• спецификация инъекции зависимостей контекста (CDI) и как она конфликтует и используется с JSF 2.0
• JQuery -- я хотел бы, чтобы вы обошлись без него.

теперь, как только вы закончите с что вы можете получить с проприетарными спецификациями, а именно библиотек компонентов и библиотек провайдеров, которые вы подберете по пути:

• PrimeFaces (моя библиотека компонентов выбора)
• RichFaces
• MyFaces
• ICEFaces
• EclipseLink (мой провайдер JPA)
• спящий режим
• сварка

и не забудьте контейнер! И все эти конфигурации файлы:

• GlassFish (2, 3 и т. д.)
• JBoss
• котяра

Итак -- это делает его легким? Конечно, JSF 2.0 "прост", если все, что вы хотите сделать, это самые простые веб-страницы с простейшими взаимодействиями.

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

1. неопытные разработчики обычно создают приложения, которые мучительно медленны, а код будет очень уродливым и трудным для обслуживания. Его обманчиво просто начать, но на самом деле требует некоторых инвестиций в обучение, если вы хотите писать хорошие программы.
2. по крайней мере, в начале вы часто "застряли" на какой-то проблеме и будете тратить больше времени на чтение сообщений balusc в интернете, чем на самом деле работает :) через некоторое время это будет все меньше и меньше, но это все еще может быть раздражающий.
3. еще более раздражает, когда вы узнаете, что проблема не из-за отсутствия знаний/ошибки, а на самом деле ошибка. Мохарра была(есть?) довольно багги, а еще один слой компонентов добавляет еще больше проблем. Richfaces был самым большим куском дерьма программного обеспечения, когда-либо написанного :) не знаю, как это теперь на версии 4. У нас есть примитивы, которые лучше, но все же вы столкнетесь с ошибками или отсутствием функций, особенно с более экзотическими компонентами. И теперь вам нужно будет заплатить за На основе схемы PrimeFaces обновления. Поэтому я бы сказал, что его багги, но его становится лучше, особенно после того, как версия 2.2 исправила некоторые проблемы со спецификацией. Рамки становятся более зрелыми, но все еще далеки от совершенства (может быть, myfaces лучше?).
4. Я не считаю его особенно гибким. Часто, если вам нужно что - то очень настроенное и нет компонентов, которые это делают-это будет немного больно. Опять же, я говорю со средней точки зрения разработчика - с крайними сроками, быстрыми учебниками по чтению и поиск stackoverflow при застревании, потому что нет времени, чтобы узнать, как это действительно работает :) часто некоторые компоненты, кажется, имеют "почти" то, что вам нужно, но не совсем, и иногда вы можете потратить слишком много времени, чтобы сделать то, что вы хотите :) нужно быть осторожным в оценке, если его лучше создать свой собственный или пытать существующий компонент. На самом деле, если вы создаете что-то действительно уникальное, я бы не рекомендовал JSF.

короче говоря, мои недостатки будут: сложность, Не очень плавный прогресс развития, глючный, негибкий.

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

" JSF выведет HTML и JavaScript уровня представления, которые вы не можете контролировать или изменять, не входя в код контроллера."

на самом деле JSF дает вам гибкость, вы можете использовать стандартные/сторонние компоненты или создавать свои собственные, которые у вас есть полный контроль над тем, что отображается. Это всего лишь один xhtml, который вам нужен для создания пользовательских компонентов с JSF 2.0.

мы разработали образец проекта с JSF (это было трехнедельное исследование, поэтому мы можем потерять некоторые вещи!)

мы пытаемся использовать core jsf, если нужен компонент, мы использовали PrimeFaces.

проект представлял собой веб-сайт с навигацией. Каждая страница должна быть загружена через ajax при нажатии на меню.

сайт имеет два использования:

1. страница с сеткой. Сетка загружается через ajax и должна поддерживать сортировку и подкачку
2. A три шага мастера. Каждая страница имеет проверку на стороне клиента (для простых проверок) и базовую проверку ajax на стороне сервера (для сложных проверок). Любое исключение сервера (из уровня сервиса) должно отображаться на той же странице мастера без перехода на следующую страницу.

мы обнаружили, что:

1. вам нужно использовать некоторые хаки из omniFaces, чтобы сделать состояние представления JSF фиксированным. Состояние JSF будет повреждено при включении страниц через ajax друг в друга. Это кажется ошибкой в JSF и может быть исправлено в следующих выпусках (не в 2.3).
2. поток JSF работает неправильно с ajax (или мы не могли заставить его работать!) Вместо этого мы пытаемся использовать компонент мастера primeface, но проверка клиента не поддерживается и означает, что он не был стандартным стандартом потока JSF.
3. при использовании некоторых компонентов jQuery, таких как jqGird, и вам нужно загрузить результаты JSON, тогда вам рекомендуется использовать чистый сервлет, JSF ничего не сделает для вас. Так если вы используете такие компоненты, ваш дизайн не будет вписываться в JSF.
4. мы пытаемся сделать некоторые клиентские скрипты, когда ajax завершается ajaxComplete и мы обнаружили, что PF 4 реализовал свои собственные события ajax. У нас были некоторые компоненты jQuery и нужно менять свой код.

Если вы измените приведенный выше образец к не Ajax project (или, по крайней мере, меньше ajax project) вы не столкнетесь с множеством вышеуказанных проблем.

мы подводим итоги нашего исследования as:

JSF не работает хорошо на полностью базовом веб-сайте ajax.

конечно, мы находим много хороших функций в JSF, которые могут быть очень полезны в некоторых проектах, поэтому учитывайте ваши потребности проекта.

пожалуйста, обратитесь к техническим документам JSF для обзора преимуществ JSF, и, на мой взгляд, самым большим преимуществом JSF, является полная и огромная поддержка от @BalusC; -)

Я вообще не эксперт по Java-серверу. Но ИМХО основным недостатком является то, что это серверная сторона. Я устал от обучения и использования фреймворков веб-презентации на стороне сервера, таких как ASP.NET веб-формы, ASP.NET MVC, Java Server Faces, Struts, PHP Framework и Ruby on rails Framework. Я попрощался со всеми, поздоровался с Angularjs и TypeScript. Мой презентационный слой работает в браузере. Я не имеет значения, обслуживается ли он Windows IIS под управлением php или ASP.NET, или если это обслуживается веб-сервером Apache, работающим на Linux. Мне просто нужно выучить только один фреймворк, который работает везде.

просто мои два цента.

для меня самым большим недостатком JSF является плохая поддержка программно (динамически) генерируемых страниц.
Если вы хотите построить свою страницу (создать модель компонента страницы) динамически из кода java. Например, если вы работаете над конструктором веб-страницы WYSIWYG. Адекватная документация этого варианта использования в общем недоступна. Есть много точек, где вы должны экспериментировать и развитие тихо медленно. Многие вещи просто не работают так, как вы ожидали. Но в целом его возможно, как-то взломать его.
Хорошо, что это не проблема в философии или архитектуре JSF. Это просто недостаточно разработано (насколько я знаю).

JSF 2 принес составные компоненты, которые должны облегчить разработку компонентов, но их поддержка динамического (программного) строительства очень плоха. Если вы преодолеете тихий сложный и почти недокументированный процесс построения динамических композитных компонентов, вы обнаружите, что если вы вложите несколько композитных компоненты немного глубже, они перестают работать, бросая некоторые исключения.

но кажется, что сообщество JSF осознает эти недостатки. Они работают над этим, как вы можете видеть из этих двух bugs
http://java.net/jira/browse/JAVASERVERFACES-1309
http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-599

ситуация должна быть лучше с JSF 2.2, по крайней мере, если речь идет о спецификации.

комментируя мои последние несколько месяцев опыта Primefaces / JSF:

• Если вы можете использовать компоненты "с полки", я думаю, это не страшно.
• тем не менее, он не играет хорошо, как только вы выходите и нуждаетесь в пользовательских UIs. - Например, нам нужно было использовать bootstrap Twitter для нашего проекта. (Не primefaces bootstrap).
  • Теперь наши страницы работают следующим образом:
    • загрузки страницы.
    • пользователь взаимодействует с Primefaces это имеет функциональность ajax
    • привязки javascript Bootstrap ломаются
    • мы запускаем дополнительный javascript для перезагрузки всего

обещание JSF избежать написания javascript превратилось в написание больше javascript, чем у нас было бы, если бы не использование Primefaces-и что javascript исправляет то, что ломает Primefaces.

это раковина времени-если вы снова не используете материал "с полки". Также очень уродливо (Primefaces) при работе с селеном. Все это можно сделать,но опять-таки, у нас не так много времени.

определенно избегайте этого, если вы работаете с командой UX/design и вам нужно быстро перебирать пользовательский интерфейс-вы можете сэкономить время, изучив jquery/написание прямого HTML-кода-или глядя на react/angular.

JSF имеет много преимуществ, вопрос о недостатке позвольте мне добавить пару очков.

на практическом сценарии реализации веб-проекта в сроки, нужно следить за следующими факторами.

• у вас достаточно старших членов в вашей команде, которые могут предложить лучшее элементы управления подходят для каждого сценария?

• У вас есть пропускная способность для размещения начального обучения кривая?

• У вас достаточно опыта в вашей команде, которая может просмотреть JSF
  вещи, производимые разработчиками?

Если ваш ответ " Нет " для вопросов, вы можете оказаться в не поддерживаемой кодовой базе.

JSF имеет только один недостаток: перед началом разработки "JSF" вы должны четко понимать веб-разработку, основную java и интерфейсную архитектуру.

В настоящее время" новые "JavaScript-фреймворки просто пытаются скопировать/вставить компонентную модель" JSF".

среди всех" основных " рамок, таких как Spring MVC, калитка, гобелен и т. д., JSF Java EE с его составными компонентами является наиболее разработанной презентационной и компонентно-ориентированной технологией. Это немного громоздко и неполно по сравнению с решениями, предоставляемыми HybridJava.