Зачем мне использовать шаблонизатор?jsp include и jstl против плиток, freemarker, скорость, sitemesh - PullRequest
92 голосов
/ 02 июля 2010

Я собираюсь выбрать способ упорядочить свое представление (с spring-mvc, но это не должно иметь большого значения)

Насколько я вижу, есть 6 вариантов (хотя они не являются взаимоисключающими):

  • Плитка
  • SiteMesh
  • Freemarker
  • Скорость
  • <jsp:include>
  • <%@ include file="..">

Плитки и Sitemesh могут быть сгруппированы; так можно Freemarker и Velocity . Какой из них в каждой группе использовать, это не предмет обсуждения, здесь достаточно вопросов и дискуссий.

Это интересное чтение , но не совсем убедить меня в использовании плиток.

Мой вопрос - что дают эти фреймворки, что не может быть правильно сделано с <@ include file=".."> и JSTL. Основные моменты (некоторые взяты из статьи):

  1. Включая части страниц, такие как верхний и нижний колонтитулы - нет разницы между:

    <%@ include file="header.jsp" %>
    

    и

    <tiles:insert page="header.jsp" />
    
  2. Определение параметров в заголовке - например, заголовок, метатеги и т. Д. Это очень важно, особенно с точки зрения SEO. С помощью шаблонов вы можете просто определить заполнитель, который должна определять каждая страница. Но в jsp вы можете использовать JSTL , используя <c:set> (на странице включения) и <c:out> (на странице включения)

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

  4. Связь между общими компонентами и конкретным содержимым - Я не вижу проблем с этим. Если вы хотите повторно использовать какой-либо фрагмент, переместите его на страницу, на которой нет верхнего или нижнего колонтитула, и включайте его везде, где это необходимо.

  5. Эффективность - <%@ include file="file.jsp" %> более эффективна, чем что-либо еще, потому что она компилируется один раз. Все остальные параметры анализируются / выполняются много раз.

  6. Сложность - все решения, не относящиеся к jsp, требуют дополнительных XML-файлов, дополнительных включений, конфигураций препроцессора и т. Д. Это и кривая обучения, и введение более потенциальных точек отказа. Кроме того, это делает поддержку и изменение более утомительным - вам нужно проверить несколько файлов / конфигураций, чтобы понять, что происходит.

  7. Заполнители - дают ли скорость / freemarker что-то большее, чем JSTL? В JSTL вы помещаете заполнитель и используете модель (помещаемую в запрос или область действия сеанса контроллерами) для заполнения этих заполнителей.

Итак, убедите меня, что я должен использовать любую из вышеупомянутых платформ вместо / в дополнение к простой JSP.

Ответы [ 7 ]

17 голосов
/ 03 июля 2010

Несколько аргументов для скорости (я не использовал Freemarker):

  • Потенциал для повторного использования шаблонов вне веб-контекста, например, при отправке электронных писем
  • Синтаксис языка шаблонов Velocity далеко проще, чем JSP EL или библиотеки тегов
  • Строгое разделение логики представления от любой другой логики - невозможно выбрать использование тегов скриптлета и выполнение неприятных действий в ваших шаблонах.

Заполнители - скорость / freemaker дают что-то большее, чем JSTL? В JSTL вы помещаете заполнитель и используете модель (помещаемую в запрос или область сеанса контроллерами) для заполнения этих заполнителей.

Да, ссылки действительно являются ядром VTL:

<b>Hello $username!</b>

или

#if($listFromModel.size() > 1)
    You have many entries!
#end

Эффективность - <%@ include file="file.jsp" %> более эффективна, чем все остальное, потому что она компилируется один раз. Все остальные параметры анализируются / выполняются много раз.

Не уверен, что я согласен или понимаю этот момент. Velocity имеет возможность кэшировать шаблоны, то есть абстрактное синтаксическое дерево, в которое они анализируются, будет кэшироваться, а не считываться с диска каждый раз. В любом случае (и у меня нет четких цифр для этого), Velocity всегда чувствовала fast для меня.

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

Разница в том, что при подходе JSP, вы не будете реорганизовывать этот макет в каждом файле JSP, который использует тот же верхний / нижний колонтитул? Tiles и SiteMesh позволяют вам указывать базовую страницу макета (JSP, шаблон Velocity и т. Д. - обе являются основой JSP), где вы можете указать все, что захотите, а затем просто делегировать фрагмент / шаблон «контента» для основного контента , Это означает, что будет только один файл для перемещения заголовка.

11 голосов
/ 12 мая 2011

Выбор между jsp:include и Tiles / Sitemesh / etc - это выбор между простотой и мощью , с которыми постоянно сталкиваются разработчики. Конечно, если у вас есть только несколько файлов или вы не ожидаете, что ваш макет будет меняться очень часто, просто используйте jstl и jsp:include.

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

Если вы уверены, что ваше приложение всегда останется простым, или вы можете установить какой-то критерий сложности приложения, после которого вы будете интегрировать одно из более сложных решений, тогда я бы рекомендовал не использовать плитки / и т. Д. В противном случае используйте его с самого начала.

4 голосов
/ 09 апреля 2014

Я не собираюсь убеждать вас использовать другие технологии. Насколько я знаю, все должны просто придерживаться JSP, если это работает для них.

Я работаю в основном с Spring MVC и нахожу JSP 2+ в сочетании с SiteMesh идеальным выбором.

SiteMesh 2/3

Предоставляет декораторы для применения к представлениям, в основном, как наследование в других шаблонизаторах. Такая функция немыслима без сегодняшней работы.

JSP 2 +

Люди, утверждающие, что JSP будет мешать избегать Java-кода в шаблонах, являются поддельными. Вы просто не должны этого делать, и с этой версией делать это не нужно. Версия 2 поддерживает вызов методов с использованием EL, что является большим преимуществом по сравнению с предыдущими версиями.

С тегами JSTL ваш код будет по-прежнему выглядеть как HTML, поэтому он будет менее неудобным. Spring очень поддерживает JSP через taglibs, что очень мощно.

Taglibs также легко расширять, поэтому настройка вашей собственной среды очень проста.

2 голосов
/ 16 августа 2011

Хорошая технология просмотра устраняет большинство и большинство раздражающих, если / switch / условные операторы, просто include не делает. Использование «сложной» технологии представления приводит к «простому» приложению.

2 голосов
/ 03 июля 2010

Один из лучших аргументов для facelets (не в вашем списке, но я просто упомяну его) против использования JSP - это то, что компиляция интегрируется с интерпретатором, а не делегируется компилятору JSP.Это означает, что одна из самых досадных вещей, которые у меня были с JSF 1.1 - необходимость изменения атрибута id в окружающем JSF-теге при сохранении изменения, чтобы механизм времени выполнения обнаружил это изменение, - ушел, давв редакторе, перезагрузите в браузере цикл назад, вместе с гораздо лучшими сообщениями об ошибках.

1 голос
/ 13 февраля 2014

Вы не предоставили информацию о конкретных ваших приложениях. Например, я не использую JSP только по нескольким причинам:

Трудно избежать использования кода Java в шаблонах JSP, так что ваша концепция разрыва в чистом View, и в результате у вас будут трудности с поддержкой кода в нескольких местах, таких как view и controller

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

JSP требует компиляции, и если целевая система не имеет Java-компилятора, любая незначительная настройка потребует использования другой системы и последующего повторного развертывания

Минимальный механизм JSP составляет около 500 Кбайт-кода плюс JSTL, поэтому он может не подходить для встроенных систем

Механизм шаблонов может генерировать различные типы контента для одной и той же модели, например, полезную нагрузку JSON, веб-страницу, текст сообщения, CSV и т. Д.

Программистам, не являющимся Java, могут быть трудности с работой с шаблонами JSP, когда неопытные люди никогда не испытывали затруднений при изменении обычных шаблонов.

Я задавал тот же вопрос давным-давно и закончил написанием своего фреймворка (конечно, на основе шаблонного движка), который был свободен от всех недостатков, которые я видел в других решениях. Излишне говорить, что это около 100 Кбайт-кода.

0 голосов
/ 13 февраля 2014

Я понимаю, что это звучит как умный ответ, но правда в том, что если вы не видите никаких преимуществ использования шаблонов по сравнению с кодом в вашем текущем проекте, это возможно потому, что в вашем текущем проекте нетне один.

Часть этого о масштабе.Вы можете подумать, что включения настолько же мощны, как, скажем, sitemesh, и это, безусловно, верно, по крайней мере, для небольшого количества страниц (я бы сказал, вероятно, около 100), но если у вас их несколько тысяч, они станут неуправляемыми.(Так что для eBay это не обязательно, для Salesforce это, вероятно, так).

Кроме того, как уже упоминалось ранее, freemarker и скорость не зависят от сервлета.Вы можете использовать их для чего угодно (почтовые шаблоны, автономная документация и т. д.).Вам не нужен контейнер сервлета для использования свободного маркера или скорости.

Наконец, ваша точка 5 верна лишь частично.Он компилируется каждый раз, когда к нему обращаются, если это еще не было сделано.Это означает, что всякий раз, когда вы что-то меняете, вам нужно помнить, чтобы удалить «рабочий» каталог ваших контейнеров сервлетов, чтобы он перекомпилировал JSP.Это не нужно для шаблонизатора.

TL; DR Шаблонизаторы были написаны для устранения некоторых (предполагаемых или реальных) недостатков JSP + JSTL.Должны ли вы их использовать или нет, полностью зависит от ваших требований и масштаба вашего проекта.

...