Преимущества использования JSTL vs Velocity для просмотра слоя в приложении MVC?

В настоящее время я создаю приложение Spring MVC. Я хотел использовать страницы JSP с библиотеками тегов для обработки слоя представления и форматирования HTML, но я столкнулся с другой группой в моей компании, которая использует шаблоны скорости для той же цели.

Из того, что я вижу, мне кажется, что между этими двумя подходами есть много общего:
  1. оба имеют простой для понимания синтаксис. Делает его легким для не-разработчиков, чтобы понять и использовать, позволяя дизайнеры должны сосредоточиться на HTML / CSS и использовать библиотеки директив / тегов только в тех немногих случаях, когда им нужны условные обозначения/динамический контент, не имея полного понимания Java.
  2. легко увидеть, какая часть содержимого является HTML, а какая-директивами / логикой.
  3. оба широко используются и хорошо поддерживаются.
  4. Простая интеграция с Spring MVC.

Но сравнивая эти две технологии, я не вижу никаких конкретных причин для их использования. другой. Мне трудно думать о каких-либо минусах, характерных для скорости или JSTL.

Итак, мой вопрос заключается в том, каковы плюсы и минусы каждого из них, по вашему мнению? Если вы создали приложение (Spring) MVC с использованием одного или другого, что заставило вас выбрать технологию слоя представления, которую вы используете, и что (если что-то) заставило вас отказаться от другого?

Update : я нашел аналогичное обсуждение этой же темы, архивированное на форуме Spring Framework здесь , что может представлять некоторый интерес для любого, кто принимает такое же решение между JSTL и скоростью, как и я.

3 11
jsp spring spring-mvc velocity

3 ответа:

Я бы предпочел использовать скорость только потому, что использование JSP+JSTL может позволить ленивым/неаккуратным разработчикам попасть в беду, добавив скриптлеты. Не должно быть никаких причин иметь java-код на уровне представления. Чтобы понять, что такое скорость, не требуется много времени, и, по правде говоря, я просто взял его в руки примерно за две недели. Хотя мне не нравится форматирование вывода, по большей части он работает довольно хорошо. Мы на самом деле не используем его на уровне представления приложения, а скорее для генерации HTML для использования другие обозреватели. Мы сохраняем выходные данные из Velocity в виде файлов, которые затем развертываются на другом сервере для использования другими веб-клиентами.

8

На самом деле я немного предпочитаю Freemarker скорости, просто на случай, если вы открыты для изучения других вариантов. Сравнение здесь:

Http://freemarker.org/fmVsVel.html

Я согласен с утверждениями Бена О применении простого представления, избегая JSP и возможности скриплетов. Мне также нравится возможность рендеринга шаблона Freemarker или Velocity в любой среде выполнения (JUnit, main() method) без необходимости использования контейнера Servlet/JSP, как это сделал бы JSP.

6

JSP также сложнее визуально отличить от встроенного HTML. Со скоростью это очень очевидно.

Кроме того, пакет VelocityTools предоставляет множество дополнительных функций.

2