Почему я должен использовать систему шаблонов в PHP?

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

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

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

Он также обеспечивает хорошую практику программирования в соответствии бизнес-логики от логики представления. Если вы смешиваете свою бизнес-логику с презентацией, вам будет сложнее извлечь ее, если вам нужно будет представить ее по-другому позже. Различные режимы презентации в веб-приложениях становятся все более популярными в наши дни: RSS / ATOM каналы, JSON или AJAX ответы, WML для портативных устройств и т.д. С помощью системы шаблонов это часто можно сделать полностью с шаблоном и нет или мало изменений в чем-либо еще.

Не все же оцените эти преимущества. Преимущество PHP перед Java/Python/Ruby / etc заключается в том, что вы можете быстро взломать веб-страницы с некоторой логикой в них, и это все хорошо и хорошо.

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

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

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

все еще есть веская причина для использования шаблонной системы, однако не Smarty, а PHPTAL. Шаблоны PHPTAL являются допустимыми файлами XML (и, следовательно, XHTML). Вы можете далее использовать фиктивный контент в PHPTAL и таким образом получить действительный файл XHTML с окончательным внешним видом, который может быть обработан и протестирован стандартными инструментами. Вот небольшой пример:

<table>
  <thead>
    <tr>
      <th>First Name</th>
      <th>Last Name</th>
      <th>Age</th>
    </tr>
  </thead>
  <tbody>
    <tr tal:repeat="users user">
      <td tal:content="user/first_name">Max</td>
      <td tal:content="user/last_name">Mustermann</td>
      <td tal:content="user/age">29</td>
    </tr>
  </tbody>
</table>

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

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

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

flickr В настоящее время использует smarty. это не должно быть так плохо, не так ли?

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

ключ состоит в том, чтобы не изменять никаких значений в коде презентации. Для этого я думаю, что PHP сам по себе так же эффективен, как Smarty, если вы используете синтаксис if/endif:

<?php if($some_test): ?>
   <em>Some text!</em>
<?php endif; ?>

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

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

if (loggedIn)
{
    // print lots of HTML here
}
else
{
    // print error message
}

в Smarty, это может быть что-то вроде этого (простите мой, возможно, неправильный синтаксис, это был а):

if (loggedIn)
{
    $smarty->bind("info", someObject);
    $smarty->display("info.template");
}
else
    $smarty->display("error.template");

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

Я счастлив, используя структуру MVC, такую как Code igniter. Я нахожу, что в "представлениях" я склонен придерживаться php-кода, который относится только к тому, как отображаются значения. У меня есть библиотека функций форматирования, которые я могу использовать в представлениях для этого. Одна из предпосылок code igniter заключается в том, чтобы избежать языка шаблонов из-за того, как он может ограничить вас и замедлить процесс.

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

вы забыли htmlspecialchars() два раза. Вот почему вам нужна система шаблонов.

Smarty-это бедные. Не судите о системах шаблонов, основанных на этом.

ваш анализ является разумным. Я полагаю:

• дизайнеры шаблонов и внутренние программисты не могут быть одним и тем же, поэтому он способствует разделению.
• Он защищает вас от себя то, что вы не можете действительно "слишком много" PHP в шаблонах.
• может быть проще оптимизировать / предварительно скомпилировать шаблоны в некоторых сценариях? (Это спекуляция)

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

одним из преимуществ шаблонного движка, которое я не видел, была возможность динамических html-элементов - что-то вроде asp.net управление. Например, с помощью HTML-шаблона PEAR Flexy вы можете иметь динамические элементы формы, которые автоматически поддерживают состояние. Обычный элемент выбора html может быть заполнен и иметь выбранный элемент, установленный в коде позади без циклов или условных обозначений в шаблоне.

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

и {$myvar|escape} ИМХО совсем немного короче, чем <?php echo htmlspecialchars($myvar); ?>. (Имея в виду, что <?=$foo?> синтаксис доступен только тогда, когда он специально включен в PHP conf.)

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

• вы хотите использовать файл с PHP кодом в качестве шаблона? Штраф.
• вы хотите использовать переменные в шаблон? Штраф.

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

• Если вы используете Zend_View или подобное, вы можете использовать PHP-код полностью.

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

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

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

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

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

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

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

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

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

Я лично всегда использую шаблонные движки в php, python или что-то еще.

первая очевидная причина, уже упомянутая другими:

Это заставляет вас не использовать бизнес-логику в ваших шаблонах.

Да, конечно, дисциплина будет просто отлично, когда у вас есть.

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

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

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

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

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

шаблон Наследство

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

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

для меня это хранитель!

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

после запуска файлов код будет сохранен это template_c. так что его не компилировать много раз.

Я несколько раз использовал tinybutstrong, который имеет довольно аккуратный и простой синтаксис. Нет циклов или псевдокод в шаблоне html.

с их домашней страницы:

TinyButStrong-это библиотека, которая позволяет динамически создавать XML / HTML страницы и любые другие файлы на основе источника текста. Это Шаблонный движок для языка PHP. Это позволяет легко отображать информация из базы данных, но и серьезно гармонизировать и упростить программирование на PHP.

TinyButStrong ориентирован на HTML, но не специализируется на Html. Этот значит он может работать также с текстовыми файлами, XML, RSS, RTF, WML, Excel (XML. ,).. В OpenTBS плагин позволяет объединить в OpenOffice и MS документ Office.

разработчики, которые будут использовать концепции OOPs сильно, как JAVA/Весна / Oracle PL-SQL люди, они говорят, что сам язык PHP используется для представления/просмотра/отображения логики в проектах уровня предприятия. В этих больших проектах бэкэнд-это Oracle, база данных извлекается с помощью pl-slq / java, а презентация-php.Лучший пример-facebook.http://en.wikipedia.org/wiki/Facebook facebook использует php для презентации, java / c++ в качестве бэкэнд-интерфейса.

единственная причина,по которой php используется в качестве презентации, потому что он тесно работает с HTML, но java/c++ больше основан на OOPs и не может быть напрямую связан с HTML. Скажите мне одну CMS(joomla/drupal/wordpress) или фреймворк (zend/symfony/Yii), которая использует Smarty? Так зачем же нужен smarty?

Мне нравится использовать шаблоны по нескольким причинам:

1) он очищает читаемость кода PHP. Мои PHP-файлы становятся раздутыми и нелюбезными, когда есть операторы печати("") с кусками HTML повсюду. Кроме того, возникают проблемы, например, как вы передаете переменные в текст HTML? Вы используете теги везде? Вы используете print ("") и экранируете свои HTML-кавычки и объединяете свои переменные? Вы используете print ("") и используете одинарные кавычки в HTML, идя против Стандарта, и вставить ваши переменные напрямую?

2) он очищает представление HTML-кода. Это может стать трудно сохранить ваш сгенерированный HTML выглядит хорошо, если он разрезан и взломан на куски через несколько файлов. Например, ваш отступ может получить путь.

3) Он позволяет создавать несколько шаблонов, а затем вошедший в систему пользователь может выбрать, какой шаблон / скин он хочет отобразить при просмотре вашего сайта, а также вы можете быстро и легко изменить значение по умолчанию шаблон для чего-то другого, если вы так склонны.

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