Недостатки JSF 2.0? Честно говоря, кроме сравнительно крутой кривой обучения, когда у вас нет глубоких базовых знаний об основах веб-разработки (HTML / CSS / JS, на стороне сервера и на стороне клиента и т. Д.) И базовом API сервлетов Java (запрос / ответ / сессия) переадресация / перенаправление и т. д.), никаких серьезных недостатков не приходит на ум. JSF в своем текущем выпуске все еще нуждается в том, чтобы избавиться от негативного имиджа, который он получил в ранние века, во время которого было несколько серьезных недостатков.
JSF 1.0 (март 2004 г.)
Это был первоначальный выпуск. Он был перегружен ошибками как в ядре, так и в областях производительности, о которых вы не хотите знать. Ваше веб-приложение не всегда работает так, как вы ожидаете. Вы как разработчик убежали бы, плача.
JSF 1.1 (май 2004 г.)
Это был релиз исправления. Производительность по-прежнему не сильно улучшилась. Был также один существенный недостаток: вы не можете безупречно встроить HTML на странице JSF. Весь простой ванильный HTML отображается перед деревом компонентов JSF. Вам нужно обернуть все простые ванили в <f:verbatim>
теги, чтобы они были включены в дерево компонентов JSF. Хотя это было в соответствии со спецификацией, это получило много критики. См. Также JSF / Facelets: почему не стоит смешивать JSF / Facelets с тегами HTML?
JSF 1.2 (май 2006 г.)
Это был первый выпуск новой команды разработчиков JSF под руководством Райана Любке. Новая команда проделала огромную работу. Были также изменения в спецификации. Основным изменением было улучшение обработки представления. Это не только полностью отделило JSF от JSP, поэтому можно было использовать технологию представления, отличную от JSP, но и позволило разработчикам встроить простой ванильный HTML-код в страницу JSF без использования <f:verbatim>
тегов. Еще одним важным направлением деятельности новой команды было повышение производительности. Во время жизненного цикла эталонной реализации Sun JSF 1.2 (под кодовым названием Mojarra начиная со сборки 1.2_08, около 2008 г.), практически каждая сборка поставлялась с (существенными) улучшениями производительности рядом с обычными (незначительными) исправлениями ошибок.
Единственный серьезный недостаток JSF 1.x (включая 1.2) - это отсутствие области между запросом и областью сеанса , так называемая область диалога . Это вынудило разработчиков беспокоиться о скрытых элементах ввода, ненужных запросах БД и / или злоупотреблении областью сеанса всякий раз, когда кто-то хочет сохранить исходные данные модели в последующем запросе, чтобы успешно обрабатывать проверки, преобразования, изменения модели и вызовы действий в более сложные веб-приложения. Боль можно смягчить, приняв стороннюю библиотеку, которая сохраняет необходимые данные в последующем запросе, такие как компонент ToFhawk MyFaces <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
для включения области диалога, не затрачивая все способы на сохранение данных в последующих (диалоговых) запросах. @ViewScoped
Фасоль будет жить до тех пор , пока вы впоследствии подачи и перемещения в ту же точку зрения (независимо от открытой вкладки браузера / окна!), Либо синхронно или асинхронно (Ajax). См. Также Разница между областью просмотра и запроса в управляемых bean-компонентах и Как правильно выбрать область действия bean-компонента?
Несмотря на то, что практически все недостатки JSF 1.x были устранены, есть ошибки, специфичные для JSF 2.0, которые могут стать пробоиной. @ViewScoped
Проваливается в обработчиках тегов из -за проблемы с куриным яйцом в состоянии частичного сохранения. Это исправлено в JSF 2.2 и перенесено в Mojarra 2.1.18. Также передача пользовательских атрибутов, таких как HTML5data-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. Если при рассмотрении фреймворка MVC вашим основным требованием является высокая степень контроля над HTML / CSS / JS, то вы должны уже не смотреть на фреймворк на основе компонентов, а на фреймворк на основе запросов, такой как Spring MVC . Вам нужно только принять во внимание, что вам придется писать все эти шаблоны HTML / CSS / JS самостоятельно. См. Также Разница между запросом MVC и компонентом MVC .
Смотрите также: