Ответ 1

PHP - это язык шаблонов.

В моем опыте до сих пор с различными системами шаблонов заключение было довольно простым: использовать none.

Вместо этого напишите PHP, как он должен быть написан! Никогда ничего не делайте внутри .html, кроме echo и for/foreach. Если вы пишете код на основе шаблона проектирования, такого как MVC, это становится еще более очевидным: просто echo и foreach внутри и объясните интерфейсы, они никогда не должны возиться с кодом внутри <?php и ?>.

Это сработало для меня с тех пор. Мне обычно было труднее объяснить их Smarty, чем объяснять, чтобы никогда не возиться с php.

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

Примечание:

Smarty, например, HARDER, чтобы найти в файле .html, потому что единственный ярлык синтаксиса Smarty, который я знаю, является плагином NetBeans и довольно бета-версией. PHP, с другой стороны, имеет синтаксис, выделенный в любом подходящем редакторе. Также проще для интерфейсов обнаруживать и не путать.

Обернуть

Минусы (для использования системы шаблонов)

• Увеличивает нагрузку на сервер (легче или тяжелее, не имеет значения - вы можете это увидеть)
• Вызывает неправильную практику (логика завершена внутри синтаксиса языка шаблонов)
• Отсутствие подсветки синтаксиса для синтаксиса языков шаблонов - сложнее определить (для кодера и интерфейса)
• Время, потраченное на изучение этого и обучение его интерфейсам
• Сложнее объяснить команде frontend (я преподавал базовый PHP для интерфейсов несколько раз), в то время как многие из них уже умеют писать собственный PHP-уровень "начального уровня", у меня есть never интерфейс Smarty, чтобы они могли делать что-то другое, кроме {$var})
• Позволяет избежать проблемы REAL: разделение логики и презентации!
• Добавляет дополнительный вес к вашему проекту

Плюсы (для использования системы шаблонов)

• Экстремальная скука (возможно, единственный действительный аргумент)

Замена системы шаблонов

• Разделение логики и презентации (я бы предложил MVC для этой задачи, а для профи он предоставляет другие области разработки: упрощение обслуживания, абстрактная база данных и т.д.)
• Заставляйте себя писать только в представлении echo и итерация для эха: foreach и for должна выполнить 99% потребностей в итерации; вы также можете использовать while и do while

Ответ 2

Для меня, когда вы решаете использовать отдельный механизм шаблонов или просто использовать PHP для шаблонов, это всегда сводится к следующему:

Когда использовать механизм шаблонов

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

Если не использовать механизм шаблонов

Все остальные времена.

Ответ 3

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

Некоторые люди, тем не менее, предпочитают использовать шаблонные движки, такие как Smarty. Есть несколько вещей, которые следует учитывать, если вы выбрали этот маршрут:

Кто собирается поддерживать шаблон? Если человек, поддерживающий шаблоны, уже знает PHP, нет смысла заставлять их изучать новый механизм псевдо-PHP-шаблонов. Если они не знают PHP, то это все еще сомнительно, в зависимости от их фона, поскольку большинство движков шаблонов просто реализуют синтаксис, не похожий на теги PHP (например, <% %>)

Насколько сложны ваши шаблоны? Некоторые шаблонные механизмы чрезвычайно ограничивают то, что вы можете сделать в шаблонах (заставляя вас поместить все в контроллер, некоторые почти до нулевой или ненужной hoop-jumping), в то время как другие примерно такие же разрешительные, как и необработанные PHP (которые многие будут утверждать, что поражает цель механизма шаблонов).

Насколько важны эффективность и скорость? Двигатели шаблонов добавляют накладные расходы. Период. Преобразование пользовательских тегов в теги PHP требует ресурсов. Насколько они добавляют и насколько это важно, зависит от ряда факторов (включая сам движок). Если вам нужно больше скорости с вашего сайта, я бы проголосовал за механизм шаблонов, как первый из них.

Как я уже сказал, я также рекомендую использовать PHP в качестве шаблона "движок", но помните о некоторых проблемах. В основном, очень легко добавить больше логики, чем необходимо, в ваши шаблоны. Удостоверьтесь, что у вас есть правило включать только echo, for/foreach и базовые if блоки (например, if is_admin() и т.п.) И убедитесь, что они принудительно применяются.

Ответ 4

Нет никаких оснований для использования механизма шаблонов php. Разделение логики и взгляда является обязательством. Это НЕ означает использование механизма шаблонов. С помощью механизма шаблонов вы должны изучать вещи, которые не имеют никакого отношения к php или делать что-либо еще. Каждый человек, который должен изменить источники smarty или другой шаблон, может быть раздражен этим дерьмом чего-то бесполезного и препятствующего беспорядку. PHP расширяет ваши шаблоны, предоставляя вам все возможности в каждом своем использовании. С дюжиной советов PHP достаточно безопасен. Не чувствуйте себя в безопасности, используя механизм шаблонов без знания трюков. Smarty не может защитить общедоступные редактируемые шаблоны.

Посмотрите на Designpatterns. Просмотреть Помощник и MVC. Держите свой код простым и хорошо структурированным - значит умнее, чем smarty/any-template-engine...

Ответ 5

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

Преимущества этого разделения:

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

Хотя технически верно, что php сам по себе является языком шаблонов, более точно он описывает его как язык веб-программирования со встроенным шаблоном. С другой стороны, верно и то, что большинство движков шаблонов потребляют шаблоны с встроенными директивами. Это означает, что существует разумный баланс между слишком большим количеством шаблонов в php и слишком большим количеством программирования в шаблоне. Чем лучше баланс, тем легче будет кодирование и более гибкое и расширяемое приложение.

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

Если, скорее, тот же самый код вызывается под управлением механизма шаблона, то у вас есть тот же код, что и на двух разных формах вывода, в зависимости от того, был ли предоставлен шаблон RSS/XML или HTML. Если механизм шаблонов хорошо написан, PHP-код не знает и не заботится о том, какой тип шаблона ему предоставляется. Php также может выводить HTML, XML, SQL, PDF или текст!

Внедрив многие веб-сайты в классическом ASP и PHP со временем, я обнаружил, что хороший механизм шаблонов спас мне много долгих часов программирования и отладки и потому что не было реального механизма шаблонов для классического ASP. Я написал KudzuASP для решения этой проблемы. Вы можете найти соответствующий проект KudzuPHP на моем сайте, и он бесплатный. Существует также плагин для Wordpress, основанный на нем.

Ответ 6

Вы всегда должны использовать какой-либо механизм для разделения разметки из кода, так же как вы не должны вставлять CSS в свой HTML. Есть слишком много вариантов, чтобы дать вам плоский ответ. Существуют шаблонные двигатели, такие как smarty или fasttemplate, тогда есть фреймворки с системами шаблонов (например, торты, воспламенители кода и т.д.). Вы должны оценивать их индивидуально в зависимости от ваших потребностей.

Ответ 7

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

Это позволяет всем работать над гораздо более чистым кодом и позволяет шаблонам оставаться простыми, чтобы те менее технические (дизайнеры интерфейсов, например) могли входить и редактировать их.

Ответ 8

Я бы просто использовал php для вашего механизма шаблонов. Никакой дополнительной перегрузки от чего-то вроде умного. Им просто нужно знать базовый php. Вы можете обозначить файлы шаблонов с расширением файла .phtml... Почему вы хотите использовать механизм шаблонов?

Чтобы быть ясным, в файлах шаблона .phtml должны быть только echos и foreachs, внутри него не должно быть кода ядра.

Ответ 9

Вы пробовали шаблонный шаблонный шаблон?

Он по-прежнему увеличивает нагрузку на сервер; однако я думаю, что он исправляет другие минусы шаблонов. В отличие от Smarty и всех других движков шаблонов для PHP, StampTE полностью логичен. Вы отмечаете только области с соответствующими комментариями HTML (большинство дизайнеров и инженеров-фронтовиков уже имеют эти маркеры только для удобства чтения). Он полагается на эти маркеры, чтобы предлагать функции вырезания и вставки для разработчиков. Back-end PHP-программисты могут копировать и вставлять эти регионы из шаблона (например, бумажные модели) и создавать с ним графические интерфейсы веб-сайтов и веб-приложений. Кроме того, у них очень удобный API. Например, чтобы разрезать область, например:

   <!-- cut:siteMenu -->
       <nav>
          <ul>
            <li>...</li>
          </ul>
       </nav>
   <!-- /cut:siteMenu -->

Они могут использовать объектно-ориентированную нотацию:

$template->getSiteMenu()->setLink( ... ); etc..

Я думаю, что это действительно круто.

http://www.stampte.com

Ответ 10

В самом деле, ключевые слова здесь разделение и повторно.

Лучший способ разработки и сегментации рабочей нагрузки внутри команды - это когда веб-дизайнер (интегратор/html-ist и т.д.) не имеет шансов сломать часть программирования (база данных, файлы, сеансы, синтаксис ошибки и т.д.).

Я рекомендую использовать FigDice Template Engine, который обеспечивает очень четкое разделение между логикой (программа, база данных, файлы, алгоритмы и т.д.). ) и Презентация (мнения и представленная ими информация) в полной безопасности.

FigDice поддерживает, конечно, макросы (многократно используемые части файла), включение, итерации и многие другие функции, а также обеспечивает эксклюзивный подход к разделению Presentation/Logics с инверсией управления поставщиками данных ( Представления извлекают информацию, необходимую им для отображения, вместо того, чтобы позволить контроллерам вводить данные в шаблоны, как это обычно бывает с практически каждым движком шаблонов). Это позволяет разработчику HTML действительно решить, что он хочет представить, и когда и как, без какого-либо риска разрушения кода.

Я был бы рад получить отзывы и комментарии. Благодаря