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

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

Из того, что я вижу, мне кажется, что между двумя подходами есть много общего:

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

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

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

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


person matt b    schedule 19.12.2008    source источник


Ответы (3)


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

person BenCourliss    schedule 19.12.2008

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

http://freemarker.org/fmVsVel.html

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

person cliff.meyers    schedule 01.01.2009
comment
Freemaker для меня - главный из них... Я пробовал его несколько раз, и это было замечательно, и не так уж сложно получить его grep за короткое время. - person engma; 28.05.2013

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

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

person Nathan Bubna    schedule 02.02.2009