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

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

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

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

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

<b>Hello $username!</b>

or

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

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

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

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

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

Выбор между jsp:include и Tiles / Sitemesh / etc - это выбор между простотой и мощностью, с которым разработчики сталкиваются постоянно. Конечно, если у вас всего несколько файлов или вы не ожидаете, что ваш макет будет меняться очень часто, просто используйте 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 Механизмы создания шаблонов были написаны для устранения некоторых (предполагаемых или реальных) недостатков JSP + JSTL. Следует ли вам их использовать или нет, полностью зависит от ваших требований и масштаба вашего проекта.