как лучше использовать Smarty с PHP? - PullRequest
7 голосов
/ 17 мая 2009

Я обнаружил, что при использовании Smarty с PHP иногда требуется дополнительное время для

1) используя совершенно другой синтаксис, чем сам PHP
2) нужно проверять мелкие случаи, потому что документация не дает более тонких деталей, например, для "escape"

http://www.smarty.net/manual/en/language.modifier.escape.php

здесь не указано escape: «кавычки» предназначены только для двойных кавычек или для одинарных кавычек, поэтому вам нужно написать код для проверки. Также для случая побега: «javascript» - не может точно сказать, что и как он избежал.

3) для чего-то сложного, нужно написать вспомогательные функции или модификаторы, поэтому ему нужно создать новые файлы и в конечном итоге сделать это снова в PHP.

кстати, обеспечивает ли использование Smarty хорошую скорость по сравнению с использованием только PHP? спасибо.

Ответы [ 11 ]

22 голосов
/ 17 мая 2009

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

Единственный «реальный» аргумент, который я когда-либо слышал об использовании ЛЮБОГО шаблонизатора, заключался в том, что они предоставляют более простой язык для манипулирования шаблонами, что может быть удобно, если у вас есть дизайнеры шаблонов, которые не знают PHP и которые вы не знаете » Не верьте, чтобы научиться разумно использовать PHP.

Что касается этих аргументов, я бы сказал, что если ваши дизайнеры шаблонов не компетентны изучать достаточно PHP для разработки шаблонов, вам, вероятно, следует подумать о поиске новых дизайнеров шаблонов. Кроме того, сам PHP предоставляет другой синтаксис для операторов управления, которые вы можете использовать в шаблоне, а не в коде. Например:

<? foreach($array as $key => $val): ?>
    <?= $val ?>
<? endforeach; ?>

VS:

<?php
    foreach($array as $key => $val) {
        echo $val;
    }

?>

Лично я считаю, что движки шаблонов возникли в PHP, потому что:

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

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

Широко использовав Smarty, я могу честно сказать, что он всегда создавал для меня больше препятствий, чем преодоление, чем решения. Во всяком случае, переключение на шаблоны на основе PHP - это то, что фактически сократило время разработки как шаблонов, так и кода.

6 голосов
/ 17 мая 2009

Я не люблю шаблонизаторы. Я нахожу их очень потерянными и ресурсоемкими для PHP.

В MediaWiki, начиная с версии 1.6.x, мы отказались от использования Smarty по умолчанию и просто использовали встроенные шаблоны PHP, что значительно улучшило производительность.

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

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

4 голосов
/ 17 мая 2009

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

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

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

Производительность является еще одним соображением. Да, рендеринг шаблона Smarty требует больших затрат. Но после того, как это сделано, вывод должен быть кэширован, что приведет к сокращению времени выполнения. То же самое касается шаблонов PHP. PHP позволяет реализовывать все виды гранулированных моделей кэширования с помощью своих выходных буферов. Но остерегайтесь преждевременной оптимизации: делайте это только после того, как закончите код и определите, какие существуют узкие места!

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

3 голосов
/ 17 мая 2009

Мне нравятся шаблонизаторы и я думаю, что их следует использовать, но в конкретном случае с Smarty я считаю, что это пустая трата времени, потому что это не значительное улучшение по сравнению с PHP как языком шаблонов:

  • Новый синтаксис все еще основан на старой концепции специальных тегов, вставляемых в произвольные места в документе.
  • Поскольку Smarty не понимает синтаксис / структуру HTML, он не может помочь вам создать правильный / правильно сформированный HTML. Теги Smarty нарушают синтаксис HTML, поэтому, как только вы добавите их, другие стандартные инструменты тоже не смогут вам помочь.
  • Вывод Smarty, как и в PHP, по умолчанию небезопасен (не удален), и вам нужно не забыть добавить |escape везде, где вы выводите данные в HTML.

Есть один конкретный шаблонизатор PHP, в который я влюбился, который исправляет все эти проблемы: PHPTAL .

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

PHPTAL, как и Smarty, компилируется один раз в PHP и кэшируется, поэтому производительность сопоставима с необработанным PHP.

2 голосов
/ 18 мая 2009

Плюсы

  • Нет PHP в ваших HTML-файлах (допускается как PHP, так и HTML-идентификация)
  • Pipes {$ var | по умолчанию: "Не выбран"} {$ var | urlencode}
  • Foreachelse: {foreach item = строка из = $ results} {$ row.name}
    {foreachelse} Нет результатов {/ foreach}
  • Тематические сайты / страницы (использование только CSS имеет свои ограничения)

Минусы

  • Синтаксис другого языка
  • Не всегда очевидный код {"Y-m-d" | strftime: $ timestamp} {$ array | @var_dump}
  • Незначительные накладные расходы

Я очень рекомендую «шаблонный» подход (mVc), но и Smarty, и обычный PHP подходят для этой задачи.

1 голос
/ 17 мая 2009

Лично я использую Blitz для шаблонов. На сайте автор утверждает, что это самый быстрый движок шаблонов и предоставляет (предвзятую?) Диаграмму производительности между различными системами шаблонов для PHP. Я сам не использовал smarty, но это может дать вам некоторые подсказки по его производительности.

http://alexeyrybak.com/blitz/blitz_en.html

1 голос
/ 17 мая 2009

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

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

1 голос
/ 17 мая 2009

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

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

Если вы уверены в своей способности разделять реализацию и представление и не проявляете реального интереса к кэшированию на стороне сервера, вам, вероятно, следует использовать только шаблоны php. Некоторые инфраструктуры MVC, такие как Zend Framework , имеют свои собственные PHP-подобные шаблоны.

С другой стороны, smarty - это достойный способ обеспечить аккуратное отделение представления от реализации, особенно там, где неясно, что и где принадлежит. Это может помочь дисциплинировать вас для обеспечения этого необходимого разделения.

Тем не менее, я использую Smarty в большинстве своих проектов PHP, так как он напоминает мне библиотеки тегов Java-Server (JSTL), к которым я очень, очень привык и очень люблю.

0 голосов
/ 09 октября 2012

Попробуйте использовать Smarty с шаблоном MVC, таким как Codeigniter, это лучше, чем ядро ​​PHP

0 голосов
/ 16 февраля 2011

Использование Smarty или нет - более или менее философская позиция.

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

Кроме того, расширение Smarty довольно просто.

В качестве примера, я добавил параметр styles в fetch (), чтобы иметь fetchUsingStyle (). Это позволяет мне легко переключаться между различными макетами сайта.

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

...