Вопрос, который возникает циклически каждый год в сообществе PHP: нужен ли нам язык шаблонов для PHP или сам язык уже достаточно практичен, чтобы вы могли писать представление на простом PHP? Для тех, кто считает, что первый вариант — правильный ответ, Twig — хороший выбор для самого языка.
Зачем принимать Twig?
Twig — это инструмент с открытым исходным кодом, который берет шаблоны, написанные на его языке, компилирует их в PHP 5.2 (и поэтому запускает их везде) и выводит их в HTML или любую разметку, на которую вы ориентируетесь. Как всегда, он устанавливается из Composer и использует его автозагрузчик, а composer.json говорит, что нет никаких зависимостей от других компонентов Symfony.
Twig — еще одно шаблонное решение; однако, это интересно, потому что это инструмент выбора для экосистемы Symfony 2. Даже будучи разработанным внутри Symfony, он не имеет связи с платформой в целом и может быть установлен и работать изолированно. Его API — это все, что вам нужно, чтобы вы создали график только с двумя внешне видимыми объектами, чтобы отобразить все ваше приложение.
Вот два простых примера из официальной документации. Первый предназначен для визуализации строк, содержащих шаблон:
$loader = new Twig_Loader_String();
$twig = new Twig_Environment($loader);
echo $twig->render('Hello {{ name }}!', array('name' => 'Fabien'));
В то время как второй обеспечивает немного более (нейтральную) абстракцию, поддерживая загрузку шаблонов из указанного каталога:
$loader = new Twig_Loader_Filesystem('/path/to/templates');
$twig = new Twig_Environment($loader, array(
'cache' => '/path/to/compilation_cache',
));
echo $twig->render('index.html', array('name' => 'Fabien'));
Один из случаев, когда тестируемость приводит к более гибкой конструкции, например, в которой вы можете воспроизводить созданные пользователем шаблоны из базы данных. Возвращаясь к системам шаблонов всего несколько лет назад, я испытал много трудностей в поиске той же функциональности, обычно скрытой или не поддерживаемой. Разделение проблем делает это простым в Twig (в то время как вы всегда можете визуализировать строки, Twig также предоставляет Inversion of Control, предоставляя Twig_LoaderInterface, который вы можете реализовать для этих случаев).
Что касается фактического синтаксиса:
<p>Hello, {{ name }}</p> <ul> {% for topic, messages in topics %} <li>{{ loop.index }}: {{ topic }}</li> {% endfor %} </ul>
Чувство хранилища GitHub
Хранилище Twig выглядит современно , по стандартам 2013 года, как и для многих компонентов Symfony. Автоматические тесты присутствуют и нацелены в основном на уровень модуля, с некоторыми интеграционными, которые работают на реальных шаблонах.
Хотя модульные тесты написаны с использованием PHPUnit, интеграционные тесты выполняются внутри PHPUnit, но написаны с расширением синтаксиса phpt. Мы рассматриваем соотношение тестовых строк 6K на 14k строк кода, которое является приемлемым для проекта с открытым исходным кодом (вы всегда можете вернуть проект и внести некоторые тесты, если покрытие отсутствует).
Более того, на уровне докоблока имеется сильная документация и подробное руководство для конечного пользователя , содержащее также несколько часто задаваемых вопросов в виде рецептов использования Twig для определенных целей. Сообщество Symfony стоит за проектом, и это может быть полезно только для долгой жизни продукта.
Я заметил, что есть расширение C для интерпретатора PHP, которое может улучшить производительность Twig, где это необходимо, например, на веб-сайтах, где вывод контента является основной задачей. Интересно, как разработчики поддерживают синхронизацию исходного кода PHP и расширения C, но я видел только один макрос PHP_FUNCTION в коде C, так что он, вероятно, все еще находится в стадии разработки.
Философские соображения
Если вам нужен язык шаблонов, распространение Twig и окружающей его экосистемы Symfony предполагает принятие по сравнению с любой другой устаревшей библиотекой (см. Smarty). Тем не менее, вопрос остается открытым, если возможно успешно использовать сам PHP как для этой цели.
С одной стороны, у Twig есть издержки, как по производительности, так и по кривой обучения, а также по 14 тыс. Строк кода сложности, которые добавляются в ваше приложение. С другой стороны, я вижу, что эти инструменты заставляют разделять проблемы, бизнес-логику и представление, так же как шаги Behat заставляют разделять автоматизацию и спецификацию.
Код hello world, ранее приведенный в этой статье, конечно же, не выиграет от использования Twig, как и все вводные примеры:
<p>Hello, <?=$name ?></p>
<ul>
<? foreach ($topics as $index => $topic) { ?>
<li><?=$index ?>: <?=$topic ?></li>
<? } ?>
</ul>
Но когда сложность возрастает, вы обнаружите, что include () не всегда лучший способ удалить дублирование. Пока вы не идете в направлении View Objects, где ваша разметка генерируется графом объектов, я бы предложил стандартное шаблонное решение, чтобы избежать потери энергии и времени на аспекте, который не является вашим конкурентным преимуществом, такой как организация вывода HTML.