Я разрабатываю свои веб-приложения, используя только PHP для файлов вида, и я никоим образом не чувствую себя ограниченным, но я слышал, что существует последовательное количество разработчиков, выступающих за «внешние» шаблонные модули. Итак, что предлагают шаблонные механизмы для простого PHP?
Я ищу практические вещи, поэтому я исключаю следующее:
<?php echo $stuff; ?> , использование фигурных скобок не имеет никакого значения) Некоторые люди не согласятся, но, поскольку я использовал 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 %} © 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. Очень полезно.
Разделение проблем.
Подобные вещи применяются в стандарте при использовании подхода MVC / MTV – где представление данных обязательно отделено от отображения данных, но не если вы используете простой OL-PHP.
Использование механизма шаблонов позволяет легко отделить то, что отображается от того, как оно отображается.
Я полагаю, вы могли бы утверждать, что это подпадает под «ухаживание за плохими разработчиками», поскольку хороший разработчик должен это делать в любом случае, но, на мой взгляд, механизм шаблонов облегчает работу и хорошим разработчикам.
Простое переключение между видами
В текущем состоянии Интернета мне необходимо предоставить мою информацию в разных форматах:
Информация для этих форматов может быть одинаковой, только вид отличается. Используя какой-то механизм шаблонов, я могу быстро переключаться между этими представлениями.
С помощью шаблонов вы также можете делегировать результаты презентации дизайнерам. Дизайнеры могут создавать шаблоны, а разработчики могут работать в логике. Также легче поддерживать презентацию.
value [key] и сортировкам. Если вы хотите разрабатывать приложения, которые могут быть настроены с использованием большого количества различных шаблонов и макетов, не отвлекая дизайн от логики, например, для разных клиентов, вам может потребоваться использовать систему шаблонов.
Но если вашим приложениям нужен только один шаблон и он никогда не меняет макет, то придерживайтесь того, что работает для вас, зачем менять? 🙂
Некоторые шаблоны моделирования могут компилировать шаблоны, что приводит к высоко оптимизированным преобразованиям. Возьмем, к примеру, XslCompiledTransform в .NET.
Ваши ответы не похожи на реальные ответы, но выражаются очень снисходительно. Например:
няня плохие разработчики (т. е. использовать механизм шаблонов, потому что это заставляет вас не смешивать код с презентацией)
Я бы назвал это заявлением о Правиле Наименее Власти . Это делает ваш шаблон более полезным для всех пользователей, а не просто «плохих разработчиков».
Ограничения – это то, что делает языки программирования. PHP не имеет встроенной функции сборки, и это не потому, что Расмус думал, что вы все «дети».
Когда я нуждаюсь в песочнице, я нахожусь в использовании шаблонов. например, разрешая пользователям размещенные шаблоны редактирования CMS.
Сначала рассмотрим ответы здесь и общий фон:
Основная причина, по которой люди используют их, состоит в том, что они обычно делают вещи немного более точными. Не вызывает сомнений, является ли это всегда чистой выгодой. Повышенная загруженность процесса обучения новому языку и отсутствие гибкости вашего языка-хозяина может в конечном итоге привести к большему недостатку, чем предлагается с использованием языка шаблонов. Twig, в частности, требует вручную экспортировать на него основные функции PHP. Лучшими языками шаблонов, которые стремятся быть краткими, было бы лучше, вместо этого расширять PHP, используя токенизатор.
Еще одна сомнительная особенность – автоматическое экранирование. Для разработчика, который кодирует очень плохо, автоматическое экранирование может быть более безопасным, но в противном случае оно ослабляет безопасность, избавляет его от ума и представляет собой ожидание того, что все будет защищено по умолчанию в любом контексте. На самом деле безопасный механизм шаблонов должен многое знать о его контексте, иногда это не всегда можно определить, только программист знает, где что-то происходит. Если вам нужно безопасное программирование, вам нужно иметь разработчика, который не зависит от автоматического выхода из строя, периода. Это также то, что PHP действительно может сделать, если вы токенизируете PHP-файл, вы можете отделить исходный текст от PHP и обернуть части PHP в буфере вывода, а затем применить любой фильтр, который вам нравится, поэтому это не эксклюзивная функция языка шаблонов.
Некоторые шаблонизаторы могут сделать предварительную генерацию немного проще и сделать предварительную компиляцию, чтобы сделать их быстрее, но это может быть достигнуто и с помощью собственных шаблонов. Существует необходимость в анализе шаблонов, которые часто делают их менее эффективными, а процесс более сложным для их использования. Введенные дополнительные шаблоны сложности значительны. Это часто может быть отвлечено от вас, но в конечном итоге выйдет на вас, например, проблемы кеширования (устаревшие записи), проблемы с исполнителями, значительно более трепетающие и беспорядочные при отладке, больше уровней и больше кода, которые вызывают гораздо больше, что может пойти не так , и т.д.
Многие функции, такие как расширение шаблонов, вам снова не нужно использовать веточку для достижения этого. Аналогично для таких вещей, как htmlspecialchars, большинство людей создадут короткие вспомогательные функции для всех функций, которые они используют очень часто.
Итак, где вы должны использовать шаблонные языки, такие как Twig?
Детей, работающих с плохими разработчиками, довольно важен, хотя я не уверен, что их следует считать разработчиками, если вам нужно использовать что-то вроде ветки, чтобы попытаться сдержать их. Вы также будете miffle хорошие разработчики, вы будете удивляться, почему они сделаны, чтобы прыгать через обручи, чтобы достичь иначе простых вещей.
Возможно, вы захотите предоставить шаблоны сторонам, где вы можете захотеть, чтобы 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 тогда есть вещи, как в конечном итоге санировать одну и ту же строку снова и снова.