Каковы основные недостатки Java Server Faces 2.0?
Вчера я увидел презентацию на Java Server Faces 2.0, которая выглядела действительно впечатляюще, хотя в настоящее время я счастливый разработчик ASP.NET MVC/jQuery. Больше всего мне понравилось JSF - огромное количество компонентов интерфейса AJAX-Enabled, которые, похоже, делают разработку намного быстрее, чем с ASP.NET MVC, особенно на AJAX-тяжелых сайтах. Тестирование интеграции выглядело очень хорошо.
Поскольку в презентации подчеркивались только преимущества JSF, я хотел бы услышать и о другой стороне.
Итак, мои вопросы:
- Каковы основные недостатки Java Server Faces 2.0?
- Что может сделать разработчик JSF рассмотреть использование ASP.NET MVC вместо JSF?
Ответы
Ответ 1
Недостатки JSF 2.0? Честно говоря, помимо относительной крутой кривой обучения, когда у вас нет достоверных знаний о базовом веб-разработке (HTML/CSS/JS, серверная сторона и клиентская сторона, и т.д.) и базовый API Java Servlet (запрос/ответ/сеанс, переадресация/перенаправление и т.д.), никаких серьезных недостатков не возникает. JSF в своем нынешнем выпуске по-прежнему должен избавиться от негативного изображения, которое он получил в раннем возрасте, в течение которого было несколько серьезных недостатков.
JSF 1.0 (март 2004 г.)
Это был начальный выпуск. Он был загроможден ошибками как в области ядра, так и в области производительности, о которой вы не хотите знать. Ваше веб-приложение не всегда работало так, как вы бы интуитивно ожидали. Вы, как разработчик, бежали от страха.
JSF 1.1 (май 2004 г.)
Это был выпуск исправлений. Производительность еще не улучшилась. Был также один главный недостаток: вы не можете встроить HTML в JSF-страницу безупречно. Весь простой ванильный HTML обрабатывается перед деревом компонентов JSF. Вам нужно обернуть все простые ванилы в теги <f:verbatim>
, чтобы они включались в дерево компонентов JSF. Хотя это было по спецификации, это получило много критики. См. Также a.o. JSF/Facelets: почему не стоит смешивать JSF/Facelets с тегами HTML?
JSF 1.2 (май 2006 г.)
Это был первый выпуск новой команды разработчиков JSF под руководством Райана Любке. Новая команда проделала большую работу. Были также изменения в спецификации. Главным изменением стало улучшение обработки представлений. Это не только полностью отсоединенный JSF от JSP, поэтому можно использовать другую технологию просмотра, чем JSP, но также позволяет разработчикам встроить простой ванильный HTML на странице JSF без сбоев с тегами <f:verbatim>
. Еще одним важным направлением новой команды было улучшение производительности. Во время жизни Sun JSF Reference Implementation 1.2 (который был под кодовым названием Mojarra с момента создания 1.2_08, около 2008 года) практически каждая сборка была дополнена (основными) улучшениями производительности рядом с обычными (незначительными) исправлениями.
Единственным серьезным недостатком JSF 1.x(включая 1.2) является отсутствие области действия между областью запросов и сеанса, так называемой области разговора. Это заставило разработчиков нервничать со скрытыми элементами ввода, ненужными запросами БД и/или злоупотреблять областью сеанса всякий раз, когда вы хотите сохранить исходные данные модели в последующем запросе, чтобы успешно обрабатывать проверки, преобразования, изменения модели и вызовы действий в более сложные веб-приложения. Боль может быть смягчена путем принятия сторонней библиотеки, которая сохраняет необходимые данные в последующем запросе, например MyFaces Tomahawk <t:saveState>
, JBoss Seam и MyFaces Orchestra.
Другим недостатком для пуристов HTML/CSS является то, что JSF использует двоеточие :
как символ разделителя идентификатора для обеспечения уникальности HTML-элемента id
в сгенерированном HTML-выходе, особенно когда компонент повторно используется несколько раз в (шаблоны, итерационные компоненты и т.д.). Поскольку это недопустимый символ в идентификаторах CSS, вам нужно использовать \
, чтобы избежать двоеточия в селекторах CSS, что приводит к уродливым и нечетным селекторам типа #formId\:fieldId {}
или даже #formId\3A fieldId {}
. См. Также Как использовать JSF сгенерированный идентификатор HTML-кода с двоеточием ": " в CSS-селекторах? Однако если вы не пурист, читайте также По умолчанию JSF генерирует непригодные идентификаторы, которые несовместимы с частью веб-стандартов css.
Кроме того, JSF 1.x не поставлялся с устройствами Ajax из коробки. Не совсем технический недостаток, но из-за обмана Web 2.0 в течение этого периода он стал функциональным недостатком. Exadel было ранним для внедрения Ajax4jsf, который был тщательно разработан в течение многих лет и стал основной частью библиотека компонентов JBoss RichFaces. Другие библиотеки компонентов также поставлялись со встроенными мощностями Ajax, хорошо известный как ICEfaces.
Примерно на половину времени жизни JSF 1.2 была внедрена новая технология представления на основе XML: Facelets, Это принесло огромные преимущества перед JSP, особенно в области шаблонов.
JSF 2.0 (июнь 2009 г.)
Это был второй крупный релиз, с Ajax в качестве модного слова. Было много технических и функциональных изменений. JSP заменяется Facelets в качестве технологии просмотра по умолчанию, а Facelets - с возможностями создания пользовательских компонентов с использованием чистого XML (так называемых составных компонентов). См. Также Почему Facelets предпочтительнее JSP в качестве языка определения вида из JSF2.0 и далее?
Силы Ajax были введены во вкусе компонента <f:ajax>
, который имеет много общего с Ajax4jsf. В укомплектовать подробный faces-config.xml
файл как можно больше, добавлены аннотации и расширенные конфигурации. Кроме того, идентификатор разделителя идентификатора контейнера по умолчанию :
стал настраиваемым, поэтому пуристы HTML/CSS могли вздохнуть с облегчением. Все, что вам нужно сделать, это определить его как init-param
в web.xml
с именем javax.faces.SEPARATOR_CHAR
и убедиться, что вы не используете символ самостоятельно нигде в идентификаторах клиента, например -
.
Наконец, но не в последнюю очередь, была введена новая область видимости. Он устранил еще один существенный недостаток JSF 1.x, как описано выше. Вы просто объявляете bean @ViewScoped
, чтобы включить область разговора, не мешая всем способам сохранить данные в последующих (разговорных) запросах. A @ViewScoped
bean будет работать до тех пор, пока вы впоследствии отправляете и перемещаетесь в один и тот же вид (независимо от открытой вкладки/окна браузера!) Либо синхронно, либо асинхронно (Ajax). См. Также Разница между областью просмотра и запроса в управляемых beans и Как выбрать правильную область bean?
Несмотря на то, что практически все недостатки JSF 1.x были устранены, существуют специфические ошибки JSF 2.0, которые могут стать showstopper. @ViewScoped
терпит неудачу в обработчиках тегов из-за проблемы с куриным яйцом в частичном сохранении состояния. Это зафиксировано в JSF 2.2 и передано в Mojarra 2.1.18. Также передача пользовательских атрибутов, таких как HTML5 data-xxx
, не поддерживается. Это зафиксировано в JSF 2.2 с помощью новой функции сквозных элементов/атрибутов. Кроме того, в реализации JSF Mojarra был собственный набор проблем. Относительно многие из них связаны с иногда неинтуитивным поведением <ui:repeat>
, новая реализация частичного сохранения состояния и плохо реализованная флэш-область. Большинство из них исправлены в версии Mojarra 2.2.x.
Вокруг JSF 2.0 время, PrimeFaces, было представлено на основе jQuery и jQuery UI. Он стал самой популярной библиотекой компонентов JSF.
JSF 2.2 (май 2013 г.)
С введением JSF 2.2 HTML5 использовался как модное слово, хотя это было технически просто поддерживается во всех старых версиях JSF. См. Также Поддержка JavaServer Faces 2.2 и HTML5, почему XHTML все еще используется. Наиболее важной новой функцией JSF 2.2 является поддержка атрибутов пользовательских компонентов, открывая таким образом мир возможностей, таких как настраиваемые группы переключателей без таргетинга.
Помимо специфических ошибок реализации и некоторых "раздражающих мелочей", таких как невозможность ввода EJB в валидатор/конвертер (уже установленный в JSF 2.3), в спецификации JSF 2.2 нет существенных недостатков.
MVC на основе компонентов и MVC на основе запроса
Некоторые могут выбрать, что основным недостатком JSF является то, что он позволяет очень мало мелкозернистого управления созданным HTML/CSS/JS. Это не JSF, а только потому, что это основанная на компонентах MVC-инфраструктура, а не основанная на MVC-инфраструктуре запрос (действие). Если высокая степень управления HTML/CSS/JS является вашим основным требованием при рассмотрении структуры MVC, то вы уже не должны смотреть на структуру MVC на основе компонентов, но на основе MVC на основе запроса, например Spring MVC. Вам нужно только учитывать, что вам придется писать все, что HTML/CSS/JS-шаблоны. См. Также Разница между запросом MVC и компонентом MVC.
См. также:
Ответ 2
После 5 лет работы с JSF, я думаю, что я могу добавить свои 2 цента.
Два основных недостатка Основные JSF:
- Большая кривая обучения. JSF является сложным, это справедливо.
- Свойство компонента . Компонентная структура пытается скрыть истинную природу Сети, которая сопровождается огромным количеством осложнений и бедствий (например, не поддерживать GET в JSF в течение почти 5 лет).
IMHO скрывает HTTP-запрос/ответ от разработчика - огромная ошибка. По моему опыту, каждая инфраструктура на основе компонентов добавляет абстракцию в веб-разработку, и эта абстракция приводит к излишним накладным расходам и более высокой сложности.
И незначительные недостатки, которые приходят мне на ум:
-
- По умолчанию идентификатор объекта состоит из идентификаторов его родителей, например form1: button1.
- Невозможно прокомментировать неправильный фрагмент страницы. Тег
<ui:remove>
требует синтаксически правильного содержимого, которое все равно анализируется. - Низкокачественные сторонние компоненты, например, не проверяйте
isRendered()
внутри processXxx()
, прежде чем продолжить.
- Включение LESS и Sencha затруднено.
- Не работает с REST.
- Не так просто для дизайнеров UX, потому что готовые к использованию компоненты имеют свои собственные стили CSS, которые необходимо перезаписать.
Не поймите меня неправильно. Как компонентная структура JSF в версии 2 действительно хороша, но она по-прежнему основана на компонентах и всегда будет...
Пожалуйста, взгляните на низкую популярность Tapestry, Wicket и низкий энтузиазм опытных разработчиков JSF (что еще более значимо).
А для контраста взгляните на успех Rails, Grails, Django, Play! Framework - все они основаны на действии и не пытаются скрыть от программиста истинный запрос/ответ и безстоящую природу.
Для меня это главный недостаток JSF. IMHO JSF может удовлетворять некоторым типам приложений (интрасеть, интенсивность форм), но для реального приложения web это не очень хороший способ.
Надеюсь, что это поможет кому-то с его/ее выбором, относящимся к интерфейсу.
Ответ 3
Несколько недостатков, которые приходят в голову:
- JSF - это основанная на компонентах инфраструктура.
Это имеет присущие ограничения, которые
связаны с соблюдением
Компонент-модель.
- AFAIK JSF поддерживает только POST, поэтому, если вы хотите ПОЛУЧИТЬ где-нибудь, у вас есть
для выполнения простого сервлета /JSP.
- Большинство компонентов пытаются обеспечить абстракции над доменами
реляционные базы данных и интерфейсные
JavaScript, и много раз эти
абстракции "протекают" и очень трудно отлаживать.
- Эти абстракции могут стать хорошей отправной точкой для младшего разработчика или кого-то, кто не устраивает какой-либо конкретный домен (например, внешний интерфейс JavaScript), но очень сложно оптимизировать производительность, поскольку задействовано несколько слоев, и большинство людей которые используют их, мало понимают, что происходит под капотом.
- Механизмы шаблонов, которые обычно используются с JSF, не имеют никакого отношения к тому, как работают веб-дизайнеры. Редакторы WYSIWYG для JSF являются примитивными и в любом случае ваш дизайнер предоставит вам HTML/CSS, которые вам придется потратить на преобразование времени.
- Такие выражения, как выражения EL, не проверяются статически, и как компилятор, так и IDE не справляются с поиском ошибок, поэтому вы получите ошибки, которые вам придется поймать во время выполнения. Это может быть хорошо для динамически типизированного языка, такого как Ruby или PHP, но если мне придется противостоять чистому раздуванию экосистемы Java, я требую напечатать свои шаблоны.
Подводя итог: Время, которое вы сохраните с помощью JSF, избегая писать шаблонный код JSP/сервлета/ bean, вы потратите его на x10, чтобы сделать его масштабированием и выполнить точно что вы хотите.
Ответ 4
Для меня самым большим недостатком JSF 2.0 является кривая обучения не только JSF, но и библиотеки компонентов, которые вы должны использовать, чтобы заставить ее делать полезную работу. Рассмотрите огромное количество спецификаций и стандартов, с которыми вы имеете дело, чтобы действительно быть опытными:
- HTML в различных воплощениях. Не притворяйтесь, что вам не нужно это знать.
- HTTP - когда вы не можете понять, что происходит, вам нужно открыть Firebug и посмотреть. Для этого вам нужно это знать.
- CSS - нравится вам это или нет. Это не так уж и плохо, и есть, по крайней мере, хорошие инструменты.
- XML - JSF, вероятно, первое место, где вы используете пространства имен в этой степени.
- Спецификация сервлета. Рано или поздно вы получите методы вызова в этом пакете. Кроме того, вы должны знать, как ваши Facelets превращаются в XHTML или что-то еще.
- JSP (в основном, вы знаете, почему в JSF это не нужно)
- JSTL (опять же, в основном, чтобы справиться с устаревшей инфраструктурой)
- Язык выражений (EL) в различных формах.
- ECMAScript, JavaScript или что-то еще, что вы хотите назвать.
- JSON - вы должны это знать, даже если вы его не используете.
- AJAX. Я бы сказал, что JSF 2.0 делает достойную работу, скрывая это от вас, но вам все равно нужно знать, что происходит.
- DOM. И как браузер использует его. См. ECMAScript.
- События DOM - тема сама по себе.
- Архитектура сохранения Java (JPA), если вы хотите, чтобы ваше приложение имело базу данных на заднем конце.
- Сама Java.
- JSEE, пока вы на нем.
- Спецификация Injection Dependency Injection (CDI) и то, как она сталкивается и используется с JSF 2.0
- JQuery - Я хотел бы видеть, как вы обойдетесь без него.
Теперь, как только вы закончите с этим, вы сможете ознакомиться с проприетарными спецификациями, а именно с библиотеками компонентов и библиотеками поставщиков, которые вы получите:
- PrimeFaces (моя библиотека компонентов)
- RichFaces
- MyFaces
- ICEfaces
- EclipseLink (мой поставщик JPA)
- Hibernate
- Weld
И не забудьте контейнер! И все эти файлы конфигурации:
- GlassFish (2, 3 и т.д.)
- JBoss
- Tomcat
Итак - ЭТО ЭТО ЛЕГКО? Несомненно, JSF 2.0 "прост", поскольку все, что вы хотите сделать, это самые простые веб-страницы с простыми взаимодействиями.
Проще говоря, JSF 2.0 - это самый сложный и громоздкий mishmash из склеенных технологий, существующих сегодня в программной вселенной. И я не могу придумать ничего, что я предпочел бы использовать.
Ответ 5
"JSF выдаст HTML-код HTML и JavaScript, которые вы не можете контролировать или изменять, не входя в код контроллера.
На самом деле JSF дает вам гибкость, вы можете использовать стандартные/сторонние компоненты или создавать свои собственные, которые у вас есть полный контроль над тем, что отображается. Это всего лишь один xhtml, вам нужно создать свои пользовательские компоненты с помощью JSF 2.0.
Ответ 6
- Неопытные разработчики обычно создадут приложения, которые очень медленны, и код будет действительно уродливым и трудным в обслуживании. Его обманчиво просто начать, но на самом деле требует инвестиций в обучение, если вы хотите написать хорошие программы.
- По крайней мере, с самого начала вы часто "застреваете" по какой-то проблеме и будете тратить больше времени на чтение балусных сообщений в Интернете, чем на самом деле.:) Через некоторое время это будет все меньше и меньше, но это все равно может раздражать.
- Еще больше раздражает, когда вы узнаете, что проблема связана не с тем, что вам не хватает знаний/ошибок, а на самом деле ошибка. Mojarra был (есть?) Довольно глючный, а еще один слой компонентов добавляет еще больше проблем. Richfaces - это самая большая часть программного обеспечения для дерьма, когда-либо написанного:) Не знаю, как это происходит в версии 4. У нас есть Primefaces, который лучше, но все же вы столкнетесь с ошибками или отсутствием функций, особенно с более экзотическими компонентами. И теперь вам нужно будет заплатить за обновления Primefaces. Поэтому я бы сказал, что его багги, но его улучшение, особенно после версии 2.2, исправили некоторые проблемы со спецификацией. Рамки становятся все более зрелыми, но все же далеки от совершенства (может быть, мои поверхности лучше?).
- Я не считаю это особенно гибким. Часто, если вам нужно что-то очень настроенное, и нет компонентов, которые это делают - это будет немного болезненно. Опять же, я говорю со средней перспективы разработчика: с крайними сроками, учебными пособиями по быстрому чтению и поиском stackoverflow, когда вы застряли, потому что нет времени, чтобы узнать, как это работает:) Часто некоторые компоненты, похоже, имеют "почти" то, что вам нужно, но не совсем так, и иногда вы можете потратить слишком много времени, чтобы заставить его делать что-то, что вам нужно:) Нужно быть осторожным в оценке того, лучше ли его создавать или пытаться использовать существующий компонент. На самом деле, если вы создаете что-то действительно уникальное, я бы не рекомендовал JSF.
Таким образом, мои недостатки были бы следующими: Сложность, Не очень плавный прогресс в развитии, ошибка, негибкая.
Конечно, есть и преимущества, но это не то, что вы просили. Во всяком случае, мой опыт работы с другими каркасами может отличаться от мнения, поэтому лучший способ - просто попробовать его на некоторое время, чтобы узнать, действительно ли его для вас (просто что-то более сложное - не наивные примеры). JSF действительно сияет там:) ИМХО лучший вариант использования для JSF - это бизнес-приложения, такие как CRM и т.д.
Ответ 7
Мы разработали пример проекта с JSF (это было трехнедельное исследование, поэтому мы, возможно, потеряли некоторые вещи!)
Мы пытаемся использовать core jsf, если нужен компонент, мы использовали PrimeFaces.
Проект был веб-сайтом с навигацией. Каждая страница должна быть загружена через ajax при щелчке по меню.
У сайта есть две возможности:
- Страница с сеткой. Сетка загружается через ajax и должна поддерживать сортировку и подкачку
- Страница с тремя шагами. Каждая страница имеет валидацию на стороне клиента (для простых проверок) и валидацию базы ajax на стороне сервера (для сложных проверок). Любое исключение сервера (из уровня сервиса) должно отображаться на той же странице мастера без перехода на следующую страницу.
Мы обнаружили, что:
- Вам нужно использовать некоторые хаки из omniFaces, чтобы сделать состояние просмотра JSF исправленным. Состояние JSF будет повреждено, если вы включите страницы через ajax друг в друга. Это кажется ошибкой в JSF и может быть исправлено в следующих выпусках (не в версии 2.3).
- JSF Flow работает некорректно с ajax (или мы не смогли заставить его работать!) Вместо этого мы пытаемся использовать компонент мастера, но проверка клиента не поддерживается и означает, что это не стандартный стандарт потока JSF.
- При использовании некоторых компонентов jQuery, таких как jqGird, и вам нужно загрузить результаты JSON, вам рекомендуется использовать чистый сервлет, JSF ничего не сделает для вас. Поэтому, если вы используете такие компоненты, ваш дизайн не будет вписываться в JSF.
- Мы пытаемся выполнить некоторые клиентские скрипты, когда ajax завершен
ajaxComplete
, и мы обнаружили, что PF 4 реализовал свои собственные события ajax. У нас были некоторые компоненты jQuery, и нам нужно изменить их код.
Если вы измените приведенный выше образец на проект не Ajax (или, по крайней мере, менее проект ajax), вы не столкнетесь с множеством вышеперечисленных проблем.
Мы обобщаем наше исследование следующим образом:
JSF не работает на полностью базовом веб-сайте ajax.
Конечно, мы находим множество приятных функций в JSF, которые могут быть очень полезны в некоторых проектах, поэтому учитывайте ваши потребности в проекте.
Пожалуйста, обратитесь к техническим документам JSF, чтобы ознакомиться с преимуществами JSF и, на мой взгляд, самым большим преимуществом JSF, является ПОЛНАЯ И ОГРОМНАЯ поддержка от @BalusC; -)
Ответ 8
Я вообще не эксперт по Java Server Faces. Но IMHO главный недостаток заключается в том, что это серверная сторона. Я устал учиться и использовать серверные среды веб-презентаций, такие как ASP.NET Web Forms, ASP.NET MVC, Java Server Faces, Struts, php frameworks и Ruby на платформах rails. Я попрощался со всеми, и я поздоровался с Angularjs и TypeScript. Мой уровень представления работает в браузере. Не имеет значения, обслуживается ли Windows IIS под управлением php или ASP.NET, или если он обслуживается веб-сервером Apache, работающим в Linux. Мне просто нужно изучить только одну структуру, которая работает повсюду.
Только мои два цента.
Ответ 9
Для меня самый большой недостаток JSF - плохая поддержка программно (динамически) сгенерированных страниц.
Если вы хотите динамически строить свою страницу (создать компонентную модель страницы) из java-кода. Например, если вы работаете над конструктором веб-страниц WYSIWYG. Адекватная документация по этому варианту использования в целом недоступна. Есть много моментов, когда вы должны экспериментировать, и разработка идет медленно. Многие вещи просто не работают, как вы ожидаете. Но, как правило, его можно взломать как-то.
Хорошо, что это не проблема в философии или архитектуре JSF. Он просто недостаточно разработан (насколько я знаю).
JSF 2 принес Composite Components, что должно облегчить разработку компонентов, но их поддержка динамической (программной) конструкции очень плохая. Если вы преодолеете тихий сложный и почти недокументированный процесс динамической компоновки составных компонентов, вы узнаете, что если вы немного гнездятся на составных компонентах, они перестают работать, бросая некоторые исключения.
Но похоже, что сообщество JSF знает об этих недостатках. Они работают над этим, как вы можете видеть из этих двух ошибок
http://java.net/jira/browse/JAVASERVERFACES-1309
http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-599
Ситуация должна быть лучше с JSF 2.2, по крайней мере, если мы говорим о спецификации.
Ответ 10
Комментируя последние несколько месяцев опыта Primefaces/JSF:
- Если вы можете использовать компоненты "с полки", я думаю, это не страшно.
- Однако он не работает хорошо, как только вы выходите на улицу и нуждаетесь в пользовательских пользовательских интерфейсах. - Например, нам нужно было использовать загрузку Twitter для нашего проекта. (Нестрочный бутстрап).
- Теперь наши страницы работают следующим образом:
- Загрузка страниц.
- Пользователь взаимодействует с Primefaces, у которого есть функция ajax
- Связывание бутстрапов javascript break
- Мы запускаем дополнительный javascript для восстановления всех.
Обещание JSF избегать написания javascript, превратившегося в писать больше javascript, чем мы могли бы использовать, если бы не использовали Primefaces, и этот javascript для исправления того, что Primefaces ломает.
Это время, когда вы снова используете материал "с полки". Также очень уродливый (Primefaces), когда приходится работать с Selenium. Все может быть сделано, но опять же - там столько времени.
Определенно избегайте этого, если вы работаете с командой UX/design и нуждаетесь в быстрой итерации в пользовательском интерфейсе - вы можете сэкономить время, изучив jquery/прямое письмо HTML или посмотрев на реакцию/ angular.
Ответ 11
JSF имеет только один недостаток: перед началом разработки JSF вы должны четко понимать веб-разработку, базовую архитектуру java и frontend.
Теперь дни "новые" js-фреймворки просто пытаются скопировать/вставить JSF-компонентную модель.
Ответ 12
Среди всех "основных" фреймворков (Spring MVC, Wicket, Tapestry и т.д. и т.д.) JSF Java EE с его составными компонентами - это наиболее разработанная технология компонентного уровня презентационного уровня. Это немного громоздко и немного не совсем по сравнению с решением, предоставленным HybridJava.
Ответ 13
JSF имеет много преимуществ, вопрос, находящийся в невыгодном положении, позволяет мне добавить пару пунктов на него.
В практическом сценарии внедрения веб-проекта с временными рамками вам необходимо следить за следующими факторами.
- У вас есть достаточно старших членов вашей команды, которые могут предложить лучшие
средства управления, подходящие для каждого сценария?
-
У вас есть полоса пропускания для размещения начальной кривой обучения?
-
У вас есть достаточный опыт в вашей команде, который может просматривать JSF
материал создается разработчиками?
Если ваш ответ "Нет" для вопросов, вы можете оказаться в неконсервативной кодовой базе.