Подтвердить что ты не робот

Каковы реальные преимущества шаблонов для двигателей только с использованием PHP?

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

Я ищу практические вещи, поэтому я исключаю следующее:

  • ухаживать за плохими разработчиками (т.е. использовать механизм шаблонов, потому что он заставляет вас не смешивать код с презентацией)
  • краткость синтаксиса (у меня есть сопоставления в Vim для таких вещей, как <?php echo $stuff; ?>, использование фигурных скобок не имеет никакого значения)
  • более простой синтаксис для не-программистов (я разрабатываю один, чтобы это не проблема)
4b9b3361

ОТВЕТЫ

Ответ 1

Новый синтаксис

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

{% for row in articles %}
 Display articles ...
{% else %}
 No articles.
{% endfor %}

Автоматическое экранирование

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

{% autoescape on %}
  Everything will be automatically escaped in this block
{% endautoescape %}

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

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

шаблон base.html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
<html lang="en">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
  {% block head %}
    <link rel="stylesheet" href="style.css" />
    <title>{% block title %}{% endblock %} - My Webpage</title>
  {% endblock %}
</head>
<body>
  <div id="content">{% block content %}{% endblock %}</div>
  <div id="footer">
    {% block footer %}
      &copy; Copyright 2009 by <a href="http://domain.invalid/">you</a>.
    {% endblock %}
  </div>
</body>

шаблон child.html

{% extends "base.html" %}

{% block title %}Index{% endblock %}
{% block head %}
  {% parent %}
  <style type="text/css">
    .important { color: #336699; }
  </style>
{% endblock %}
{% block content %}
  <h1>Index</h1>
  <p class="important">
    Welcome on my awesome homepage.
  </p>
{% endblock %}

Детский шаблон может переопределять блоки для стилей страницы, содержимого и т.д. Вы также можете заметить использование {% parent%}, которое захватывает контент для родителей, чтобы вы не потеряли его во время переопределения.

Я рекомендую вам дать Twig a go. Очень полезно.

Ответ 2

Разделение проблем.

Подобные вещи используются в стандарте при использовании подхода MVC/MTV - где представление данных обязательно отделено от отображения данных, но не если вы используете простой ol PHP.

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

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

Ответ 3

Простое переключение между видами

В текущем состоянии Интернета мне необходимо предоставить мою информацию в разных форматах:

  • Статическая страница html
  • Динамически загруженный вид на другой HTML-странице
  • Объект данных JSON
  • XML файл данных, используемый в моей flash-части

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

Ответ 4

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

Ответ 5

  • Я использую свой собственный "шаблонный" движок, довольно простой материал, присваиваю value [key] и виды.
  • Когда я впервые искал механизм шаблонов, я нашел умный, но у меня было так много проблем с безопасностью, что я в конечном итоге написал то, что мне было нужно.
  • Ты спрашиваешь почему? потому что у него есть много функций, которые могут ускорить ваше кодирование (что бы вы не подумали и не могли ли вы делегировать систему шаблонов вместо вашего кода).
  • Большинство кодеров там выбрали систему шаблонов, и, работая в команде, вам нужно поддерживать стандарт.

Ответ 6

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

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

Ответ 7

Некоторые шаблонные модули могут компилировать шаблоны, приводящие к высоко оптимизированным преобразованиям. Возьмем, к примеру, XslCompiledTransform в .NET.

Ответ 8

Ваши ответы не похожи на реальные ответы, но сформулированы очень снисходительно. Например:

няня плохих разработчиков (т.е. использовать механизм шаблонов, потому что он заставляет вас не смешивать код в презентации)

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

Ограничения - это языки программирования. PHP не имеет встроенной функции сборки, и это не потому, что Расмус думал, что вы все "дети".

Ответ 9

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

Ответ 10

Сначала рассмотрим ответы здесь и общий фон:

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

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

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

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

Итак, где вы должны использовать шаблонные языки, такие как Twig?

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

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

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

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

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

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

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

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

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

Аналогично, я недавно исследовал выход из Twig. В частности, выделялось ускорение JS, которое поддерживало ускорение строк JS и других странных вещей, а не просто использование json_encode. Вероятно, пользовательское экранирование будет таким же, как и в фреймворках. Обычно он более надежный и безопасный, чтобы сделать это самостоятельно (пока вы знаете о таких вещах, как то, что происходит, если вы JSON кодируете строку, содержащую и создаете ее как литерал javascript без достаточного экранирования, например).

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