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

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

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

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

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

  • Для дерева компонентов ui механизм синхронизации для синхронизации состояния представления, динамически измененного на стороне клиента (через JS/jQuery) с соответствующим состоянием представления на сервере. p >

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

    Таким образом, потребуется синхронизирующий механизм, правильно?

  • Оптимально экстернализированные (где-то централизованные) правила навигации для
    (а) произвольная межстраничная навигация (статические правила навигации) и
    (b) "волшебная" навигация (динамические правила навигации, динамически определяемые из  текущее состояние/результат).

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

Очевидными вопросами являются:

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

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


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

ОТВЕТЫ

Ответ 1

JSF:

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

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

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

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

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

Ответ 2

Калитка:

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

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