Зачем мне использовать шаблонизатор? jsp include и jstl vs плитки, freemarker, скорость, sitemesh

95

Я собираюсь выбрать способ организации своего представления (с помощью 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.

java jsp velocity tiles freemarker Божо
источник
Я не совсем уверен, как бы сравнивать их, потому что я уже некоторое время использую шаблоны макета Stripes и считаю, что это намного лучше, чем простой JSP. Я использую некоторые вызовы jsp: include, но это, как правило, особые случаи. Механизм шаблонов макетов - действительно удобный и мощный инструмент.
Pointy
2
да, я слышал, что все это «удобно и мощно», но не видел. Однако я видел ненужную сложность и груды файлов конфигурации. (Я говорю не о полосах конкретно, а в целом)
Божо
1
См. Также stackoverflow.com/questions/610062/…
matt b
Я считаю, что jsp: include довольно эффективен - он скомпилирован до вызова метода из включающего сервлета в включаемый. Это приводит к меньшему количеству сгенерированного кода, чем @include, что может даже улучшить производительность из-за эффектов кеширования.
Том Андерсон
Разработчик StringTemplate приводит лучший аргумент, который я видел, который очень похож на правило наименьшей мощности
Пол Свитт

Ответы:

17

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

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

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

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

<b>Hello $username!</b>

или

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

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

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

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

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

Мэтт Би
источник
3
приведенные вами примеры скорости можно легко выполнить с помощью JSTL. с точки зрения эффективности я имею в виду, что jsps компилируются в сервлеты, и ничего не анализируется. Но шаблоны кеширования - тоже хорошее решение, да. Что касается реорганизации - нет, я обычно формирую включения таким образом, что мне нужно изменять только включения, а не «включающие». Возможно, в более сложных случаях это невозможно.
Bozho
2
Помимо повторного использования шаблонов вне веб-контекста, Velocity позволяет легко захватить отрисованную веб-страницу, прежде чем она будет отображена клиенту. Это полезно, когда вы хотите, чтобы ваш сайт создавался в виде файлов HTML. С JSP - непростое решение. Это была основная причина, по которой мы перешли на Velocity с JSP. Что касается скорости - я провел несколько тестов, и Velocity рендерила страницы ровно в 2 раза быстрее, чем JSP. Так что скорость не проблема. Теперь, проведя с Velocity несколько лет, я больше никогда не вернусь к JSP. Это намного проще, легче и чище.
serg
@ serg555 у вас есть эти тесты где-нибудь? Мне бы хотелось увидеть больше данных об этом. Мне было бы интересно увидеть, как вы выполнили тест. Я думаю, что это будет хорошей информацией для других, размышляющих над тем же вопросом «Скорость против JSP против других движков».
matt b
У меня нет опубликованных результатов. Просто я конвертировал несколько страниц с нашего сайта и замерил время рендеринга до и после. Ничего слишком научного :)
serg
@ serg555 какая платформа / контейнер сервлетов / версия jsp?
Bozho
12

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

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

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

пришвартованные
источник
5

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

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

SiteMesh 2/3

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

JSP 2+

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

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

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

Барт
источник
Я не вижу пользы для SiteMesh. Теги Jsp предлагают те же функции декорирования, что и SiteMesh, но с большей гибкостью, менее хрупкой настройкой, и я бы предположил также большую эффективность, поскольку не требуется пост-обработки.
Магнус
2

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

Торбьёрн Равн Андерсен
источник
Да, для JSF Facelets является решение только из-за тесной интеграции с переводчиком. Но здесь это не тот случай :)
Божо
Я просто упомянул об этом на тот случай, если у любого из них будет такая же функция - это будет для меня решающей особенностью.
Thorbjørn Ravn Andersen
2

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

Ибрагим
источник
1

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

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

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

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

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

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

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

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

Singagirl
источник
0

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

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

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

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

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

Миккель Лёкке
источник