В настоящее время я обсуждаю выбор между PHP как механизмом шаблона и движком шаблона поверх PHP.
Каков ваш выбор и почему?
Я говорю, зачем использовать другой механизм шаблонов, когда PHP является самим шаблоном.
В настоящее время я обсуждаю выбор между PHP как механизмом шаблона и движком шаблона поверх PHP.
Каков ваш выбор и почему?
Я говорю, зачем использовать другой механизм шаблонов, когда PHP является самим шаблоном.
Для двигателей шаблонов:
Для plain-php:
Я предпочитаю сам PHP, если это вообще возможно. И большинство людей не хотят взламывать ваше программное обеспечение, создавая специальную тему, поэтому легко бегло читать и исследовать его безопасность. Тем не менее, я "между парнем", который выполняет как шаблонизацию, так и программирование, и даже некоторые графики; мой набор навыков отличается от строгого программиста и строгого художника/дизайнера.
Я обнаружил, что, когда я представил Smarty, было довольно просто заставить веб-дизайнеров создавать HTML файлы с гибкими переменными. Люди в команде разработчиков теперь сосредоточены на большей объемной работе, т.е. На производстве содержимого переменных Smarty.
Это сократило жизненный цикл разработки, при этом работа могла быть разделена между большим количеством людей и в конечном итоге привела к лучшим проектам.
Ну, это только мое мнение, но шаблоны двигателей сосать. Вы должны сначала понять, как работает механизм шаблонов, а затем узнать, как его использовать. Кажется, это просто потерянное время, потому что только PHP делает это лучше всего и предлагает гораздо большую гибкость.
Применяются следующие причины:
Использование механизма шаблона может быть полезно, если у вас есть не-программист, делающий шаблоны. Во многих случаях упрощенный язык шаблонов может быть проще для не-программиста, чем сам PHP.
Тем не менее, я нахожу, что ухожу от использования шаблонов, когда это только я (или я и другие разработчики).
PHP не механизм шаблона, а язык, который можно использовать для написания шаблонов или движков шаблонов. Механизм шаблонов - это не только язык, но и API программирования, который позволяет скриптам находить, организовывать шаблоны или назначать им данные из script. Чистый PHP предлагает вам абсолютно ничего - это просто язык. Вместо этого вы должны брать такие библиотеки, как Zend_View в Zend Framework, для сравнения (в основном, он работает точно так же, как Smarty, за исключением того, что он использует PHP для написания шаблонов). Вы должны спросить, следует ли использовать механизм шаблонов с PHP или что-то еще в качестве языка шаблонов.
Когда речь идет о шаблонах самих языков, тогда хорошо... обычных циклов и условий достаточно, чтобы писать шаблоны, но это "достаточно" не означает, что это легко, удобно, эффективно или гибко. PHP не предлагает ничего особенного для дизайнеров шаблонов, но многие "шаблонные языки" (например, Smarty) предоставляют только ограниченное подмножество PHP, поэтому я не удивлен, что программисты выбирают PHP. По крайней мере, они могут писать функции и использовать ООП, которые слишком масштабны для этого (на мой взгляд), но действительно помогают и действительно помогают.
Дело в том, что пользовательские языки шаблонов не ограничены недостатками PHP, но их дизайнеры не видят его, утверждая, что "отображения переменных и цикла достаточно". Возможные области, где языки шаблонов могут быть намного эффективнее:
Примеры шаблонов языков, которые следуют за этим способом, упоминаются выше PHPTAL и Open Power Template 2. Некоторые аналогичные идеи также можно найти в TinyButStrong, но, к сожалению, этот механизм шаблонов очень медленный.
PHP отлично подходит для большинства задач, но механизм шаблонов может облегчить масштабирование проекта.
С полки, такие как Smarty или PHPTAL отлично, если у вас нет времени, чтобы катиться самостоятельно (и не требуйте больше, чем они предлагают). Кроме того, вы можете довольно легко заменить или изменить их своей собственной версией позже, если найдете, что вам нужно что-то более специализированное.
У меня лично был хороший опыт работы с PHPTAL, в первую очередь потому, что он не срабатывает и прост.
PHP в качестве механизма шаблонов не будет жаловаться, когда вы смешиваете свой синтаксис HTML. Это позволит вам забыть закрыть теги, неправильно установить их и т.д.
Выход PHP по умолчанию не экранируется, поэтому, если вы не заметили, чтобы строго добавить htmlspecialchars()
повсюду, ваш сайт будет иметь уязвимости HTML-инъекций (XSS).
<p>Hello <?= $name ?></b>
<!-- Simple template full of errors -->
Эти проблемы намного хуже, если вы пытаетесь правильно генерировать XHTML . Это не то, что вы не можете сделать это с помощью простого PHP - конечно, можете, но это требует больших усилий и усердия.
Savant - это то, что вы ищете. Его класс классной оболочки, который позволяет вам использовать PHP-шаблоны в ваших шаблонах вместо того, чтобы интерпретировать новый язык шаблонов поверх PHP.
Плюсы:
Имеет смысл не добавлять дополнительную работу в систему.
Кривая обучения для разработчиков
Если вы все дисциплинированы, то это путь. (Савант)
Минусы:
Хотя Savant поощряет вас отделить должным образом, это не заставляет разработчика отделять бизнес-логику от кода разработки. У меня есть правило, которое никогда не должно быть нарушено. Вы можете выводить только переменные, использовать условия и циклы в своих шаблонах. Вы никогда не должны позволять разработчику создавать переменные в шаблоне. К сожалению, разработчики никогда не делают этого независимо от того, сколько раз вы им рассказываете. Таким образом, использование такого движка, как Smarty, становится таким, потому что разработчики вынуждены полностью поддерживать бизнес и дизайн.
Если я делаю проект для себя или того, у кого нет многих разработчиков, я предпочитаю использовать Savant. Если его проект намного больше, чем только я, то в архитектуре я пойду на что-то вроде Smarty.
В любом случае, разделение в коде - важная погода, в которой вы используете Savant или Smarty. Я уверен, что есть и другие хорошие варианты.
Я нашел, что создание легкого шаблона шаблонов в 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 is secure).
Хороший шаблонный двигатель (например, Twig) предлагает:
Если бы мне пришлось потратить время на изучение автономного механизма шаблонов, я предпочел бы потратить время на изучение Framework. Мой выбор состоит в том, чтобы пойти с Zend Framework, который при реализации с использованием MVC-подхода предоставляет вам мощь фреймворка, а также собственные возможности шаблонирования самого PHP.
Поскольку я задал этот вопрос, я столкнулся с mustache. Это логический шаблонный язык.
Таким образом, это не то же самое, что PHP или smarty, где у вас есть возможность добавить к вам всевозможные логики, но заставляет вас хранить всю логику в чем-то вроде моделей просмотра.
Мне кажется, что это лучший вариант, а затем переход на язык шаблонов, где логика по-прежнему возможна.
в настоящее время он наиболее быстрый и простой в использовании. Сделав набор тестов на PHP-шаблонах, веточка появляется на втором месте сразу после родного языка php.
Я использую механизм шаблонов в PHP, потому что предпочитаю иметь высокую степень разделения между бизнес-логикой и логикой представления. Веб-программирование намного проще, когда ваш PHP (или любой другой язык программирования) не имеет HTML, разбросанного по всему миру. Это код Microsoft позади настолько популярен.
Я использую механизм шаблонов под названием KudzuPHP. Это порт моего KudzuASP для классического ASP. Он отличается от многих механизмов шаблонов тем, что код, который содержит бизнес-правила и логику, становится обработчиком событий для механизма шаблона после вызова механизма шаблона. Этот подход позволяет вам изменять шаблоны (перемещение больших блоков представления), не требуя изменения кода кода PHP.
KudzuPHP содержит свою собственную библиотечную систему, и писать новые теги и библиотеки расширений очень просто.
Здесь вы можете найти KudzuPHP: http://www.andrewfriedl.com/downloads/ Если вам нужна версия, встроенная в плагин Wordpress, которая позволяет вам кодировать API Wordpress без PHP, перейдите на Wordpress.org и найдите плагины для "Казу".