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

https://stackoverflow.com/questions/436014

22-07-2019
|

Вопрос

Причина, стоящая за моим вопросом, такова:PHP сам по себе является многофункциональной системой создания шаблонов, почему я должен устанавливать другой движок шаблонов?

Единственные два плюса, которые я нашел на данный момент, это:

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

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

Небольшой пример:

PHP

<h1><?=$title?></h1>
<ul>
  <? foreach ($items as $item) {?>
  <li><?=$item?></li>
  <? } ?>
</ul>

Умный

<h1>{$title}</h1>
<ul>
  {foreach item=item from=$items}
  <li>{$item}</li>
  {/foreach}
</ul>

Я действительно не вижу вообще никакой разницы.

Решение

Да, как вы сказали, если вы не заставляете себя использовать движок шаблонов внутри PHP ( the templating engine ), становится легко поскользнуться и перестать разделять проблемы.

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

Смотрите также:

Другие советы

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

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

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

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

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

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

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

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

Все еще есть веская причина для использования системы шаблонов, однако не Smarty, а ПХПТАЛ.Шаблоны 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 автоматически вставит все значения из массива users и заменит наши фиктивные значения.Тем не менее, таблица уже является допустимым 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() дважды.Вот почему вам нужна система шаблонов.

Умник беден.Не судите о системах шаблонов, основываясь на этом.

Ваш анализ вполне обоснован.Я полагаю:

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

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

Одним из преимуществ шаблонизатора, которого я не заметил, была возможность создания динамических html-элементов - что-то вроде asp.net элементов управления.Например, с помощью HTML-шаблона Flexy от PEAR вы можете создавать динамические элементы формы, которые автоматически поддерживают состояние.Обычный элемент выбора 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 (приложения).Для управления шаблонами Smarty не требуется знаний PHP.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Я несколько раз использовал крошечный, но сильный, который имеет довольно аккуратный и простой синтаксис.В 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-файлы становятся раздутыми и некрасивыми, когда повсюду появляются инструкции print ("") с фрагментами HTML.Кроме того, возникают вопросы, например, как вы передаете переменные в HTML-текст?Вы везде используете теги?Используете ли вы print(""), экранируете ли ваши HTML-кавычки и объединяете ли ваши переменные?Используете ли вы print("") и используете ли одинарные кавычки в HTML, что противоречит стандарту, и вставляете ли свои переменные напрямую?

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

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

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

Лицензировано под: CC-BY-SA с атрибуция

Не связан с StackOverflow