Альтернативы JSP для слоя представления Spring MVC
Я надеюсь создавать новое приложение с нуля и буду, вероятно, использовать Spring MVC и возможно веб-Поток Spring. Проекты, созданные Кенгуру Spring, используют Spring MVC и дополнительно веб-Поток. Каковы некоторые хорошие альтернативы для технологии представления, или JSP с Spring и JSTL taglibs и jQuery способ пойти?
6 ответов
В стандартном API Java EE единственной альтернативой JSP являются Facelets . На данный момент (2010 г.) JSF является единственной платформой MVC, которая изначально поддерживает Facelets.
Spring MVC "из коробки" поддерживает только JSP, но имеет настраиваемый преобразователь представлений , который позволяет вам в любом случае использовать Facelets . Другими кандидатами являются сторонние структуры шаблонов, такие как Velocity , Freemarker и Thymeleaf , которые можно настроить как технологию просмотра для Spring MVC. В документации Spring есть примеры интеграции с Velocity и Freemarker.
Я использую скорость и Spring MVC. Кроме того, я размещаю свое приложение на движке приложений Googles, и у меня нет проблем.
Spring MVC обеспечивает интеграцию с множеством различных технологий представления. Я бы рекомендовал использовать FreeMarker или Velocity.
Я использую Stripes и Spring вместе. Полоски не мешают вам большую часть времени, но я нахожу, что они отлично дополняют Spring, когда вам это нужно.
Документация по Springs 3 также предлагает FreeMarker. Freemarker (насколько я могу судить) быстр и имеет некоторую интеграцию функций Spring, таких как связывание.
(Мой предыдущий ответ здесь сильно устарел.) Freemarker по крайней мере так же хорош, как Velocity. Но Thymeleaf выглядит еще более привлекательным, вместе с layout-dialect он может сделать ненужными такие шаблонные фреймворки, как sitemesh и tiles. Что касается JSF, то критика Thoughtworks кажется обоснованной:
Мы продолжаем наблюдать, как команды сталкиваются с проблемами при использовании JSF - JavaServer Faces - и рекомендуем вам избегать этой технологии. Похоже, что команды выбирают JSF, потому что это стандарт Java EE, не оценивая, подходит ли им эта модель программирования. Мы считаем, что JSF несовершенен, потому что его модель программирования поощряет использование собственных абстракций, а не полностью принимает лежащую в основе веб-модель. JSF, как и веб-формы ASP.NET, пытается создать деревья компонентов с состоянием поверх HTML-разметки и протокола HTTP без состояния. Улучшения в JSF 2.0 и 2.2, такие как введение представлений без статических данных и продвижение GET, являются шагами в правильном направлении, возможно, даже признанием того, что первоначальная модель была несовершенна, но мы считаем, что это слишком мало и слишком поздно. Вместо того чтобы разбираться со сложностью JSF, мы рекомендуем командам использовать простые фреймворки и тесно работать с веб-технологиями, включая HTTP, HTML и CSS.