JSF 2.0 против Wicket против SpringMVC 3.x для особых требований

Question

В поисках веб-фреймворка, пригодного для моих нескольких критических требований в новом проекте Java EE 6, я прочел здесь множество тем по этой теме, и, наконец, смог сократить число предполагаемых фреймворков до JSF 2.0 , Wicket 1.4 (среди на основе компонентов ) и SpringMVC 3 (среди на основе действий ).

Что касается этих платформ, мне понадобится несколько советов , если и, возможно, как , реализуются следующие требования:

1. Предпочтительно разделить рабочий процесс конструктора / кодера, чтобы дизайнеры - оптимально - могли независимо разрабатывать свои файлы HTML, CSS, JS / jQuery с помощью своих любимых инструментов, таких как Dreamweaver .

2. Простая интеграция многих существующих (причудливых и анимированных) компонентов jQuery, таких как Скользящая панель входа в систему (демонстрацию можно увидеть здесь ).Таким образом, на самом деле требуется простая интеграция с выходом из кода HTML + CSS + jQuery и ТАКЖЕ:

3. Для дерева компонентов пользовательского интерфейса механизм синхронизации для синхронизации представлениясостояние динамически изменяется на стороне клиента (через JS / jQuery) с соответствующим состоянием просмотра на сервере.

   Полагаю, мне это нужно.Например, представьте себе вышеупомянутую «скользящую панель входа в систему», имеющую «открытый» или «закрытый», изменяемый на стороне клиента через JS.Его начальное состояние запрограммировано на «закрытие», и пользователь решает, что на стороне клиента всегда поддерживать его открытым.Теперь, когда пользователь перемещается куда-то и снова возвращается к этому представлению, состояние панели входа в систему нежелательно «закрыто», а не «открыто» (так как это его начальное состояние, и на стороне сервера не происходили обновления динамического состояния).

   Таким образом, механизм синхронизации будет необходим, верно ???

4. Оптимально экстернализованные (где-то централизованные) правила навигации для
   (a) произвольной межстраничной навигации (правила статической навигации) и
   (b) «как у волшебника»навигация (правила динамической навигации динамически определяются из текущего состояния / результата).

5. Хорошая производительность (время загрузки, потребление памяти сервером, опытный отклик и т. д.).
   

Очевидные вопросы:

1. Какие из этих требований (хорошо) поддерживаются JSF2, Wicket и Spring MVC3, а какие нет?

2. Как правило, с этими требованиями - и, поскольку я до сих пор не уверен с техническими аспектами / последствиями: какой тип структуры (компонент на основе действия) следует выбрать в этом случае(то есть, какие критические аспекты решения или «практические правила» следует иметь в виду)?

Большое спасибо за ваш совет и помощь.
Мартин

Answer 1

JSF:

1. На языке шаблонов JSF (Facelets) это легко.Вы просто пишете обычный HTML и добавляете только атрибут jsfc для динамических частей.См. Статью в Википедии для быстрого примера: http://en.wikipedia.org/wiki/Facelets
2. Используя составные компоненты JSF, это действительно легко.Просто поместите свой jquery в файл .xhtml, добавьте небольшой заголовок, и он будет использоваться везде как компонент.Многие компоненты, основанные на jquery, также доступны напрямую, используя PrimeFaces
3. JSF, превосходный в этом механизме синхронизации.Синхронизация происходит через четко определенное и простое для понимания количество шагов.По сути, этот механизм синхронизации является более или менее основной причиной использования JSF вместо прямой записи jquery.
4. JSF имеет именно это и даже называется именно 1013 *.Они представляют собой мощный механизм определения навигации во внешнем XML-файле.Правило навигации может быть определено на основе логических результатов и / или действий, выполняемых на определенных страницах.Они могут быть основаны на переадресации или перенаправлении, с дополнительными параметрами или без них.
5. JSF overal работает очень хорошо.Он сохраняет (сохраняет) состояние, так что это стоит вам немного памяти, но он достаточно умен, чтобы сохранить его только частично (значения отличаются от их исходных значений).Кроме того, вы можете решить сохранить это состояние на клиенте или сервере.Из-за очень удобного view scope небольшие объемы данных, используемые вашей логикой поддержки, могут очень легко кэшироваться между запросами.Это избавляет вас от попадания в БД после каждого запроса и может значительно повысить производительность.

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

Поскольку модель компонентов JSF стандартизирована и очень четко задокументирована, многие, многие сторонние организации предоставляют готовые библиотеки компонентов.Например, RichFaces, Primefaces, OpenFaces, IceFaces, Тринидад ... список почти бесконечен.

Некоторые дополнительные замечания о производительности.Сравнивая любую из трех веб-платформ, вы упоминаете, что разница незначительна, и, как правило, веб-фреймворк не там, где большая часть времени тратится на обработку запроса.Это почти всегда в базе данных и в IO.

Веб-инфраструктура может помочь, упрощая предотвращение перехода к БД, но даже если веб-инфраструктура A в 10 раз быстрее в синтетических тестах, которые затрагивают только веб-слой, чем инфраструктура B, то на практике вы вряд лизаметьте это, если только 5% времени запроса тратится в этих рамках.

Answer 2

Wicket:

1. Предпочтительно отдельный рабочий процесс дизайнера / кодировщика: возможно благодаря использованию стандартных HTML и CSS.Дизайнеры редактируют HTML, разработчики Java.В HTML есть только некоторые маркеры (атрибуты wicket: id), чтобы определить, где будут динамические компоненты.
2. Простая интеграция jQuery: используйте WiQuery , который интегрирует компоненты JQuery с Wicket.Используя WiQuery, вы можете интегрировать и другие компоненты JQuery, которые могут быть переданы обратно (WiQuery с открытым исходным кодом).
3. Для дерева компонентов пользовательского интерфейса есть механизм синхронизации [..]: Wicket и WiQuery справятся с этим за васв большинстве случаев.Wicket отслеживает состояние на стороне сервера и может обрабатывать обновления частей страницы для вас (встроенные).
4. Оптимально экстернализованные (где-то централизованные) правила навигации: Динамическое переключение для Wizards легко (это просто Java).Ссылки просто указывают на класс Page, который вы хотите показать, переключение на эту страницу при нажатии выполняется для вас.
5. Хорошая производительность: это полностью зависит от вашего варианта использования.Wicket можно кластеризовать и масштабировать, поэтому для 99% случаев вы получаете «хорошую производительность».

Некоторые общие замечания: мне очень нравится компонентная модель Wicket.Это очень легко написать свои собственные компоненты и поведения.Объектно-ориентированная модель Wicket действительно мощная.