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

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

Несколько аргументов в пользу скорости (я не использовал 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 по своей сути), где вы можете указать все, что хотите, а затем просто делегировать фрагменту / шаблону "контент" для основного контента. . Это означает, что будет только один файл, в который нужно переместить заголовок.

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

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

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

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

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

SiteMesh 2/3

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

JSP 2+

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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