Выбор правильного шаблонного движка

Question

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

С поиском в Google я нашел Freemaker, Velocity и Tiles, которые кажутся очень известными. Есть ли у кого-нибудь из вас дальнейшие опыты с некоторыми из них, и можете ли я кратко рассказать об этом.

Или есть другие фреймворки, на которые стоит обратить внимание?

Answer 1

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

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

Если вы хотите узнать больше об этом предмете / философии, прочитайте Обеспечение строгого разделения модельного представления в шаблонизаторах создателем StringTemplate.

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

1. представление не может изменить модель либо путем непосредственного изменения модели объекты данных или путем вызова методов на модель, вызывающая побочные эффекты. То есть шаблон может получить доступ к данным из модели и вызывать методы, но такие ссылки должны быть побочным эффектом свободно. Это правило возникает частично потому что ссылки на данные должны быть порядок учета регистра. См. Раздел 7.1.
2. представление не может выполнять вычисления на зависимых данных значения , потому что вычисления могут изменить в будущем, и они должны быть аккуратно заключены в модель в любой случай. Например, представление не может рассчитать цены продажи книг как «$ Цена * 0,90». Быть независимым от модель, вид не может сделать предположения о значении данных.
3. представление не может сравнивать значения зависимых данных , но может проверить свойства данных, таких как наличие / отсутствие или длина многозначное значение данных. Тесты как $ bloodPressure <120 должен быть перемещен в модель, как врачи хотели бы сохранить снижение максимального систолического давления на нас. Выражения в представлении должны быть заменен на тест на наличие значение, имитирующее логическое значение, такое как $ bloodPressureOk! = null Вывод шаблона может зависеть от данных модели и вычисления, условные должен быть рассчитан в модели. Четное простые тесты, которые дают отрицательные значения красный должен быть рассчитан в модели; правильный уровень абстракции обычно союзник что-то более высокого уровня, такого как «Отдел Х теряет деньги». </li>
4. представление не может делать предположения типа данных. Некоторые предположения типа очевидно, когда представление предполагает данные значение, например, дата, но больше предположения тонкого типа: если шаблон предполагает, что $ userID является целое число, программист не может измените это значение на нечисловое в модели, не нарушая шаблон. Это правило запрещает массив индексирование, такое как colorCode [$ topic] и $ name [$ ID] Вид далее не может вызывать методы с аргументами, потому что (статически или динамически) есть предполагаемый тип аргумента, если только один может гарантировать метод модели просто относился к ним как к объектам. К тому же графические дизайнеры не программисты; ожидая, что они призовут методы и знать, что передать нереально.
5. данные из модели не должны содержать информацию о дисплее или макете. Модель не может пройти ни одного дисплея информация для представления под видом значения данных. Это включает в себя не прохождение название шаблона для применения другие значения данных.

Answer 2

• Velocity - старик из движков Java-шаблонов, и он это показывает. Дизайн немного хрустящий (много статических методов), он немного ограничен и не очень расширяем. Тем не менее, он отлично работает, и хорошо интегрируется с Spring MVC .
• Freemarker начался там, где остановился Velocity. У него гораздо больше функциональности, он очень расширяемый, он очень хорошо интегрируется с Spring MVC. С другой стороны, я нахожу язык выражения шаблона очень своеобразным.
• Плитка, с которой у меня нет опыта, хотя любая связь со Struts вызывает у меня подозрение.

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

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

Answer 3

Если вам нравится язык программирования Scala , вам может понравиться Scalate , поскольку он позволяет вам использовать мощные выражения Scala вместо ограниченного языка выражений JSP / JSF / JSTL EL - при этом полностью статически типизированы, поэтому шаблоны проверяются во время редактирования / компиляции на наличие ошибок.

Шаблоны Scaml в Scalate позволяют вам создавать действительно СУХИЕ шаблоны, которые особенно хороши для XML / HTML (фанаты Rails обычно любят Haml, а Scaml - это порт Scala Haml) - хотя, если вы Привыкнув к JSP, вам, вероятно, будет лучше начать с шаблонов Ssp в Scalate, похожих на JSP.

Answer 4

Я работал с Velocity и FreeMarker вместе со Spring MVC. Хотя Velocity действительно легкий и простой в использовании, он каким-то образом ограничен. Я предпочитаю FreeMarker для рендеринга веб-страниц из-за больших существующих библиотек макросов и поддержки включения JSP.

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

Итак, если вам не нужны фантазии страниц AJAX, результат будет следующим: Freemarker + SiteMesh + Spring MVC. Но если вам интересно, использовать AJAX или нет, я рекомендую вам взглянуть на GWT showcase .