Почему я должен использовать шаблонный движок? jsp include и jstl vs плитки, freemarker, скорость, sitemesh

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

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

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

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

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

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

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

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

    и

    <tiles:insert page="header.jsp" />

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

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

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

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

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

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

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

ОТВЕТЫ

Ответ 1

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

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

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

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

<b>Hello $username!</b>

или

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

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

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

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

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

Ответ 2

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

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

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

Ответ 3

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

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

SiteMesh 2/3

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

JSP 2 +

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

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

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

Ответ 4

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

Ответ 5

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

Ответ 6

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

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

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

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

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

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

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

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

Ответ 7

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

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

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

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

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