В настоящее время я обсуждаю выбор между PHP как механизмом шаблонов и движком шаблонов поверх PHP.
Каков ваш выбор и почему?
Я говорю, зачем использовать другой механизм шаблонов, когда PHP является самим шаблоном.
Для шаблонных движков:
Для plain-php:
Я предпочитаю сам PHP, если это вообще возможно. И большинство людей не хотят взламывать ваше программное обеспечение, создавая специальную тему, поэтому легко бегло читать и исследовать его безопасность. Тем не менее, я «между парнем», который выполняет как шаблонизацию, так и программирование, и даже некоторые графики; мой набор навыков отличается от строгого программиста и строгого художника / дизайнера.
Я обнаружил, что, когда я представил Smarty, было довольно просто заставить веб-дизайнеров создавать HTML-файлы с гибкими переменными. Люди в команде разработчиков теперь сосредоточены на большей объемной работе, т. Е. На производстве содержимого переменных Smarty.
Это сократило жизненный цикл разработки, при этом работа могла быть разделена между большим количеством людей и в конечном итоге привела к лучшим проектам.
Ну, это только мое мнение, но шаблоны двигателей сосать. Вы должны сначала понять, как работает механизм шаблонов, а затем узнать, как его использовать. Кажется, это просто потерянное время, потому что только PHP делает это лучше всего и предлагает гораздо большую гибкость.
Применяются следующие причины:
Использование механизма шаблона может быть полезно, если у вас есть не-программист, который делает шаблоны. Во многих случаях упрощенный язык шаблонов может быть проще для не-программиста, чем сам PHP.
Тем не менее, я обнаружил, что ушел от использования шаблонов, когда это только я (или я и другие разработчики).
PHP не является механизмом шаблона, а языком, который можно использовать для написания шаблонов или движков шаблонов. Механизм шаблонов – это не только язык, но и API-интерфейс программирования, который позволяет скриптам находить, организовывать шаблоны или назначать им данные из сценария. Чистый PHP предлагает вам абсолютно ничего – это просто язык. Вместо этого вы должны брать такие библиотеки, как Zend_View в Zend Framework, для сравнения (в основном, он работает точно так же, как Smarty, за исключением того, что он использует PHP для написания шаблонов). Вы должны спросить, следует ли использовать механизм шаблонов с PHP или что-то еще в качестве языка шаблонов.
Когда речь заходит о шаблонах самих языков, то хорошо … обычных циклов и условий достаточно, чтобы писать шаблоны, но это «достаточно» не означает, что это легко, удобно, эффективно или гибко. PHP не предлагает ничего особенного для дизайнеров шаблонов, но многие «шаблонные языки» (например, Smarty) предоставляют только ограниченное подмножество PHP, поэтому я не удивлен, что программисты выбирают PHP. По крайней мере, они могут писать функции и использовать ООП, которые слишком масштабны для этого (на мой взгляд), но действительно помогают и действительно помогают.
Дело в том, что пользовательские языки шаблонов не ограничены недостатками PHP, но их дизайнеры не видят этого, утверждая, что «отображения переменных и цикла достаточно». Возможные области, где языки шаблонов могут быть намного эффективнее:
Примеры шаблонов языков, которые следуют за этим способом, упоминаются выше PHPTAL и Open Power Template 2. Некоторые подобные идеи также можно найти в TinyButStrong, но, к сожалению, этот механизм шаблонов очень медленный.
PHP в качестве механизма шаблонов не будет жаловаться, когда вы смешиваете свой синтаксис HTML. Это позволит вам забыть закрыть теги, неправильно установить их и т. Д.
Вывод PHP не удаляется по умолчанию, поэтому, если вы не htmlspecialchars() строго добавить htmlspecialchars() повсюду, ваш сайт будет иметь уязвимости HTML-инъекций (XSS).
<p>Hello <?= $name ?></b> <!-- Simple template full of errors -->
Эти проблемы намного хуже, если вы пытаетесь правильно генерировать XHTML. Дело не в том, что вы не можете сделать это с помощью простого PHP – конечно, можете, но это требует больших усилий и усердия.
Вот почему моя рекомендация – PHPTAL . OPT2 тоже в порядке.
Savant – это то, что вы ищете. Его класс классной оболочки, который позволяет вам использовать PHP-шаблоны в ваших шаблонах вместо того, чтобы интерпретировать новый язык шаблонов поверх PHP.
Плюсы:
Имеет смысл не добавлять дополнительную работу в систему.
Кривая обучения для разработчиков Если вы все дисциплинированы, то это путь. (Савант)
Минусы:
Хотя Savant поощряет вас отделить должным образом, это не заставляет разработчика отделять бизнес-логику от кода разработки. У меня есть правило, которое никогда не должно быть нарушено. Вы можете выводить только переменные, использовать условия и циклы в своих шаблонах. Вы никогда не должны позволять разработчику создавать переменные в шаблоне. К сожалению, разработчики никогда не делают этого независимо от того, сколько раз вы им рассказываете. Таким образом, использование движка, такого как Smarty, становится стоить того, потому что разработчики вынуждены полностью поддерживать бизнес и дизайн.
Если я делаю проект для себя или того, у кого нет многих разработчиков, я предпочитаю использовать Savant. Если его проект намного больше, чем только я, то в архитектуре я пойду на что-то вроде Smarty.
В любом случае, разделение кода – важная погода, в которой вы используете Savant или Smarty. Я уверен, что есть и другие хорошие варианты.
PHP отлично подходит для большинства задач, но механизм шаблонов может облегчить масштабирование проекта.
С полки, такие как Smarty или PHPTAL , великолепны, если у вас нет времени, чтобы сворачивать свои собственные (и не требуйте больше, чем они предлагают). Кроме того, вы можете довольно легко заменить или изменить их своей собственной версией позже, если найдете что-то более специализированное.
У меня лично был хороший опыт работы с PHPTAL, прежде всего потому, что он держится на вашем пути и прост.
Я нашел, что создание легкого шаблона шаблонов в PHP работает лучше всего для нас. Позволяет для хорошего разделения кода, и наш графический дизайнер мог бы изучить несколько простых правил, которым нужно следовать, но большинство пишет HTML / CSS, а не PHP. Я могу написать тяжелый код, не думая о интерфейсе.
Следующая статья подводит итог различным точкам зрения о Template Engines для PHP.
Выполнение PHP-шаблонов третьего вида http://www.tinybutstrong.com/article_3rd_kind.html
PHP не является шаблоном для языка скриптов.
Мой выбор для любого нового проекта, вероятно, состоял бы в том, чтобы просто использовать возможности шаблонирования PHP, возможно, в сочетании с каркасом MVC, вместо использования другого механизма шаблонов. В конце концов, для простоты кода или чистоты разделения не имеет значения, есть ли у вас {$myVar} или <?= $myVar ?> В вашем коде. Более сложные шаблонные функции, такие как условия, циклы или бэкэнд-технологии, такие как кеширование, могут быть обработаны также (или лучше) с помощью PHP или структуры MVC.
Я использовал оба подхода (с и без механизма шаблонов), но только в личных проектах, никогда в командных проектах, поэтому, возможно, есть веские аргументы в пользу использования механизма шаблонов в такой настройке.
Я не знаю, связано ли это с VirtueMart, Joomla или концепцией шаблонов в PHP, но настройка VirtueMart на вашу собственную графическую тему – PURE HELL. (Я не говорю о простой CSS-моделировании.)
Функции кодирования PHP эволюционировали, функция проектирования одинакова, поэтому, если вы работаете в команде с дизайнерами и разработчиками, вам нужен механизм шаблонов для распараллеливания задания и позволяйте дизайнерам работать с HTML.
Мой личный выбор – Raintpl, потому что он легкий, дружелюбный и быстрый здесь. Тест может помочь вам выбрать (также умные и умные!):
Я недавно написал сообщение в блоге об этом.
Только ради безопасности, определенно используйте механизм шаблонов (Twig безопасен).
Хороший шаблонный двигатель (например, Twig) предлагает:
Если бы мне пришлось потратить время на изучение автономного механизма шаблонов, я предпочел бы потратить время на изучение Framework. Мой выбор состоит в том, чтобы пойти с Zend Framework, который, когда он реализован с использованием MVC-подхода, предоставляет вам мощь фреймворка, а также собственные возможности шаблонирования самого PHP.
Поскольку я задал этот вопрос, я столкнулся с усами . Это логический шаблонный язык.
Таким образом, это не то же самое, что PHP или smarty, где у вас есть возможность добавить к вам всевозможные логики, но заставляет вас держать всю логику в чем-то вроде моделей просмотра.
Мне кажется, это лучший вариант, а затем переход на язык шаблонов, где логика по-прежнему возможна.
Я использую механизм шаблонов в PHP, потому что предпочитаю иметь высокую степень разделения между бизнес-логикой и логикой представления. Веб-программирование намного проще, когда ваш PHP (или любой другой язык программирования) не имеет HTML, разбросанного по всему миру. Такой код Microsoft настолько популярен.
Я использую механизм шаблонов под названием KudzuPHP. Это порт моего KudzuASP для классического ASP. Он отличается от многих механизмов шаблонов тем, что код, который содержит бизнес-правила и логику, становится обработчиком событий для механизма шаблона после вызова механизма шаблона. Этот подход позволяет вам изменять шаблоны (перемещение больших блоков представления), не требуя изменения кода кода PHP.
KudzuPHP содержит собственную библиотечную систему, и писать новые теги и библиотеки расширений очень просто.
Вы можете найти KudzuPHP здесь: http://www.andrewfriedl.com/downloads/ Если вам нужна версия, встроенная в плагин WordPress, которая позволяет вам кодировать API WordPress без PHP, перейдите на WordPress.org и найдите плагины для " Kazoo».
в настоящее время он наиболее быстрый и простой в использовании. Сделав набор тестов для PHP-шаблонов, веточка появляется на втором месте сразу после родного языка php.