[info]ru_java


ru.java

все о языке программирования java


Previous Entry Add to Memories Share Next Entry
Freemarker: ваше мнение?
[info]bbseva wrote in [info]ru_java
Стоим перед выбором template engine. Есть люди рекомендующие freemarker. Я имел опыт общения с ним и он мне не очень понравился в виду своей малой похожести на xml и неочевидным синтаксическим сахаром.

Кто-нибудь может указать очевидные минусы/плюсы по сравнению с jsp/taglibs?

PS продублировал тут: http://habrahabr.ru/qa/16740/
Tags:

На больших проектах очень хорошо себя зарекомендовал.

Спасибо. А чем? У нас и jsp + sitemesh + taglibs неплохо пашут.

Зависит от задачи, разумеется. Если планируется делать веб-приложения, то надо смотреть в контексте фреймворка.

Да, здесь конечно речь идет о веб приложении. Фреймворк - что вы имеете ввиду? Мы юзаем Спринг - но там что freemarker, что jsp нормально встраиваются.

В целом да, у Спринга более-менее все равно.

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

Хм, забавное применение. А не видели какой-нибудь статьи про это - чтобы ознакомиться?

есть люди рекомендующие и иглоукалывание. смотреть надо в контексте задачи.

Ок, переформулирую вопрос - для каких целей нужен Freemarker?

"FreeMarker is a "template engine"; a generic tool to generate text output (anything from HTML to autogenerated source code) based on templates."

вот - неплохое сравнение.

Да, спасибо, не видел. Единственно, что аргументы так себе, в контексте веб-приложений, например вот этот пункт:
- "Virtually unnoticeable delay when visiting a page for the first time (or after it was changed), because no expensive compilation happens." означает ли он, что страница транслируется каждый раз, как в php? ИМХО, скомпилированный jsp в class будет быстрее работать если страница меняется раз в релиз.

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

А также быстро превращающийся массивный набор ftl шаблонов в кашу из инструкций, приправленный кодом для логики во View.

Не факт, ибо експрешн леншвидж евалюейтится в рантайме, так что компиляция такая себе. А во что транслируются теги вы видели? А безкончные вызовы out.write...

"скомпилированный jsp в class будет быстрее"

вот уж неправда.

плюс если компилировать в класс, кто этот класс потом сможет удобно выгрузить? (то ли дело, интерпретатор; кэш часто используемых страниц забился - какую-то страничку вон)

Разница разве что на высоконагруженных сайтах, жсп типа компилируются и теоретически могут работать со скоростью Си. А строки во фримаркере может кешируются, может кешируются в кеше файловой системы, а может перечитываются с диска. Вычисление сложных выражений было бы быстрее в жсп, если бы jstl-like expr тоже компилировались, но они, увы, вычисляются из строк.

НУ ещё jsp можно при странных ошибках "посмотреть под капот" (сорцы).

А так примерно то же самое.

О, это годный комментарий. Спасибо.

Так а вот, то что freemarker никуда не компилируется. Он каждый раз разбирает шаблон, вычисляет из строк его же экспрешшены и т.п.? Не знаете?

"теоретически"

в том-то и дело.

это ж чем должен заниматься сервер, чтобы компиляция и оптимизация JSP стала самой важной задачей?

Я больше с Velocity работал, до Freemarker пока руки не дошли, но уже полюбил темплитин енджайны.

Чистый JSP это ведь спагетти код. Зато быстрый. Хотя уже трансляция в сотни вызовов out.write(...) вроде как не самый логичный для перформенса ход. Хотя это мелочь.

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

JSTL очень ограничен, и в то же время ужасно verbose. Чтоб if/else написать choose/when/otherwise конструкция просто чрезмершейне verbose.

И JSTL или Custom теги, полюбому будет expression language, который тоже ограничен излишне, и еще и евалюейтается в рантайме как строчка. Какое там кеширование я не знаю кстати, вполне вероятно что оно медленнее Velocity/Freemarker.

Пример кода из real life: есть куча объектов, с методами вроде getTitle(Locale locale, boolean useFallback), getDescription(Locale locale, boolean useFallback). Expression language такой вызов не позволяет, something.title => something.getTitle(), и всё.

Кастом теги? Надо сначала его написать. Потом такой код родить например:
<my:title obj="${something}" locale="${locale}" useDefault="true" var="titleVal" />
<c:out value="${titleVal}" />
Уродство форменное, куча текста, кругом евалюейтающийся в рантайме екпрешн ленгвидж, кастом тег, под объект заточеный.

Альтернативно без кастом тегов - скриптлеты+JSTL:
<%
Something theSomehting = (Something)pageContext.findAttribute("something");
String titleVal = theSomething.getTitle(locale, true);
pageContext.setAttribute("titleVal", titleVal);
%>
<c:out value="${titleVal}" />

А теперь, например, то-же на Velocity:
$!escapeTool.html($something.getTitle($locale, true))

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

Что-то такое.
Простите за сумбурность.

эпоха jsp 1.x закончилась аж 9 лет назад.

Таглибы сейчас очень просто пишутся на самом языке jsp,
выражения типа c:out value="${titleVal}" достаточно писать как ${titleVal}



Edited at 2012-02-23 08:25 am (UTC)

> выражения типа c:out value="${titleVal}" достаточно писать как ${titleVal}
Хм, это скорее пугает - а как без ескейпинга вывести строчку тогда?

> Таглибы сейчас очень просто пишутся на самом языке jsp,
Я этого не видел. Пусть я на 9 лет отстал, но всё равно, я уверен что там в этих новых таглибах свои западлянки напоявлялись.

И тем не менее, пусть даже я не прав и таглибы пишутся на ура - вычеркните часть "наваять таглиб" из моего комента, но остальное то остаётся.

P.S. Понял о чём вы (-:
Я знаю что можно просто ${titleVal} писать в JSP 2.0 (-:
Но вывод в HTML почти везде ескейпится, там c:out не из необходимости а для дела.

Как это относится к таглибам на самом JSP? Никак.

Согласно этому:
http://stackoverflow.com/questions/4812755/difference-between-jsp-el-jsf-el-and-unified-el
"Dec 2009: EL 2.2 was introduced with JSP 2.2 / Java EE 6 which now allows for calling concrete bean action methods instead of only calling Javabean getters/setters inside #{} syntax, e.g. #{bean.method(argument)}."

Т.е. ЖеЕсПе догнало темплитин енджайны в вопросе вызова методов... в 2009-м, в JSP2.2. Чудно.

http://adamgent.com/post/6091183966/jsp-el-2-1-versus-el-2-2
Cannot agree more.

Edited at 2012-02-23 09:03 am (UTC)

P.S. Таглибы на самом JSP это не конец эпохи JSP 1.x,
В JSP 2.0 только Expression Language полноценный добавился, так что вы многовато лет отставания мне приписали.
Нашёл про .tag файлы - JSP2.1, в 2006-м спека вышла только.

Edited at 2012-02-23 09:06 am (UTC)

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

используйте то, что лучше знаете, что больше нравится большинству вовлеченных разработчиков.

Да, я примерно так и делаю.

Но тут есть такие забавные люди, которые говорят буквально следующее: "Вы в jsp можете написать логику на java, а freemarker вам теоретически сделать это не позволит". Я резонно возражаю: "Позвольте! Если в команде договорились, что мы этого не делаем, то как оно там может появиться?" и ловлю на себе многозначительные взгляды... Конечно хочется возразить, что я при таком подходе могу и тупо фримаркер "случайно" вырезать или сбоку уютненько на jsp приписать, но вообще аргумент конечно атомный.

Это какие-то бредни.
Фримаркер не может делать Java вызовы разве?
Velocity может (ограничения только в вызове конструкторов и статик методов), на нём можно писать определённую "логику" тоже, это же не Stringtemplate. Такчто ничем он радикально не стесняет.