Я создаю сайт на php с большим количеством страниц, и мы работаем над ним командой из 9 человек. Поэтому просто хочу изучить это, когда мы должны использовать PHP-шаблоны, и когда мы этого не сделаем. Поэтому меня интересуют плюсы и минусы использования PHP-шаблонов, поэтому я могу принять решение, использовать ли это в моем случае или нет.
По моему опыту до сих пор с различными системами шаблонов, вывод был довольно прост: использовать нет .
Вместо этого напишите PHP, как он должен быть написан! Никогда ничего не делайте внутри .html, кроме echo и for / foreach . Если вы пишете код на основе шаблона проектирования, такого как MVC, это становится еще более очевидным: просто echo и foreach внутри и объясняйте интерфейсы, они никогда не должны возиться с кодом внутри <?php и ?> .
С тех пор это работало для меня. Мне обычно было труднее объяснить им Smarty, чем объяснять, чтобы никогда не испортить php.
Шаблонные системы также добавляют вес вашему серверу (иногда это немного, иногда вы можете это почувствовать). Сначала это может показаться чрезмерной оптимизацией, но я предпочитаю держать ее как можно проще.
Заметка:
Smarty, например, HARDER обнаруживает в .html-файле, потому что единственный ярлык синтаксиса Smarty, который я знаю, является плагином NetBeans, и это довольно бета-версия. PHP, с другой стороны, имеет синтаксис, выделенный в любом подходящем редакторе. Кроме того, проще, чтобы интерфейсы отображались и не возились.
{$var} ) echo и итерацию для echo : foreach и for должны выполнить 99% потребностей в итерации; вы также можете использовать while и do while Для меня, когда вы решаете использовать отдельный механизм шаблонов или просто использовать PHP для шаблонов, это всегда сводится к следующему:
Когда использовать механизм шаблонов
Когда вы должны ограничить (sandbox) код, который можно запустить в шаблонах.
Когда не использовать механизм шаблонов
Все остальные времена.
Пуристы PHP скажут вам, что PHP сам по себе является механизмом шаблонов. Я считаю себя пуристом по этому вопросу и рекомендую использовать PHP. Он даже имеет альтернативный синтаксис для блоков if и loop, которые в значительной степени предназначены для чтения в стиле шаблонов.
Однако некоторые люди предпочитают использовать шаблонные движки, такие как Smarty. Есть несколько вещей, которые следует учитывать, если вы выбрали этот маршрут:
Кто будет поддерживать шаблон? Если человек, поддерживающий шаблоны, уже знает PHP, нет смысла заставлять их изучать новый механизм псевдо-PHP-шаблонов. Если они не знают PHP, то это по-прежнему вызывает сомнения, в зависимости от их фона, поскольку большинство движков шаблонов просто реализуют синтаксис, не похожий на теги PHP (например, <% %> )
Насколько сложны ваши шаблоны? Некоторые шаблонные механизмы чрезвычайно ограничены в том, что вы можете делать в шаблонах (заставляя вас поместить все в контроллер, некоторые почти до нулевой или ненужной обручи), в то время как другие примерно такие же разрешительные, как и необработанные PHP (которые многие будет утверждать, что он поражает цель механизма шаблона).
Насколько важна эффективность и скорость? Двигатели шаблонов добавляют накладные расходы. Период. Преобразование пользовательских тегов в теги PHP требует ресурсов. Насколько они добавляют и насколько это важно, зависит от ряда факторов (включая сам движок). Если вам нужно больше скорости с вашего сайта, я бы проголосовал за механизм шаблонов, как первый из них.
Как я уже сказал, я также рекомендую использовать PHP в качестве шаблона «движок», но помните о некоторых проблемах. В основном, очень легко добавить больше логики, чем необходимо, в ваши шаблоны. Убедитесь, что у вас есть правило для включения только echo , for/foreach и базового, if блоки (например, if is_admin() и т. П.) И убедитесь, что они принудительно применяются.
Механизм шаблонов следует использовать, когда есть много презентаций, которые дублируются на нескольких веб-страницах, и у вас есть желание отделить бизнес-приложение и прикладное программирование и логику от презентации.
Преимущества этого разделения:
Хотя технически верно, что php сам по себе является языком шаблонов, более точно описать его как язык веб-программирования со встроенным шаблоном. С другой стороны, верно и то, что большинство движков шаблонов потребляют шаблоны с встроенными директивами. Это означает, что существует разумный баланс между слишком большим количеством шаблонов в php и слишком большим количеством программирования в шаблоне. Чем лучше баланс, тем легче будет кодирование и более гибкое и расширяемое приложение.
Возьмем, например, PHP-код, который извлекает ваши последние 10 сообщений в блоге и записывает их в тег DIV в вашем блоге при вызове этого кода. Если этот же код был продублирован для создания RSS-канала, у вас будет один и тот же код в двух местах, требующий сохранения его в нескольких местах при изменении логики.
Если, скорее всего, тот же самый код вызывается под управлением механизма шаблона, то у вас есть тот же код, что и на двух разных формах вывода, в зависимости от того, был ли предоставлен шаблон RSS / XML или HTML. Если механизм шаблонов хорошо написан, PHP-код не знает и не заботится о том, какой тип шаблона ему предоставляется. Php также может выводить HTML, XML, SQL, PDF или текст!
Внедрив многие веб-сайты в классическом ASP и PHP со временем, я обнаружил, что хороший механизм шаблонов спас мне много долгих часов программирования и отладки, а также потому, что не было реального механизма шаблонов для классического ASP. Я написал KudzuASP для решения этой проблемы. Вы можете найти соответствующий проект KudzuPHP на моем сайте, и он бесплатный. Существует также плагин для WordPress, основанный на нем.
Нет абсолютно никаких оснований использовать механизм шаблонов php. Разделение логики и взгляда является обязательством. Это НЕ означает использование механизма шаблонов. С помощью механизма шаблонов вы должны изучать вещи, которые не имеют никакого отношения к php или делать что-либо еще. Каждый человек, который должен изменить источники smarty или другой шаблон, может быть раздражен этим дерьмом чего-то бесполезного и препятствующего беспорядку. PHP расширяет ваши шаблоны, предоставляя вам все возможности в каждом своем использовании. С дюжиной советов PHP достаточно безопасен. Не чувствуйте себя в безопасности, используя механизм шаблонов без знания трюков. Smarty не может защитить общедоступные редактируемые шаблоны.
Посмотрите на Designpatterns. Просмотреть Помощник и MVC. Держите свой код простым и хорошо структурированным, значит умнее, чем smarty / any-template-engine …
Вы всегда должны использовать какой-либо механизм для разделения разметки из кода, так же как вы не должны вставлять CSS в свой HTML. Есть слишком много вариантов, чтобы дать вам плоский ответ. Существуют шаблонные двигатели, такие как smarty или fasttemplate, тогда есть фреймворки с системами шаблонов (например, торты, воспламенители кода и т. Д.). Вы должны оценивать их индивидуально в зависимости от ваших потребностей
Я бы предложил использовать некоторый метод хорошего разделения между вашей логикой отображения и другими данными, получающими maniuplation. Реализация MVC – отличный способ сделать это, и большинство фреймворков PHP обеспечивают структуру MVC.
Это позволяет всем работать над гораздо более чистым кодом и позволяет шаблонам оставаться простыми, чтобы те менее технические (дизайнеры интерфейсов, например) могли входить и редактировать их.
Я бы просто использовал php для вашего механизма шаблонов. Никакой дополнительной перегрузки от чего-то вроде умного. Им просто нужно знать базовый php. Вы можете обозначить файлы шаблонов с расширением .phtml … Почему вы хотите использовать механизм шаблонов?
Чтобы быть ясным, в .phtml шаблонов .phtml должно быть только echos и foreachs внутри .phtml не должно быть кода ядра.
Вы пробовали Stamp Template Engine?
Он по-прежнему увеличивает нагрузку на сервер; однако я думаю, что он исправляет другие минусы шаблонов. В отличие от Smarty и всех других движков шаблонов для PHP, StampTE полностью логичен. Вы отмечаете только области с соответствующими комментариями HTML (большинство дизайнеров и инженеров-фронтовиков уже имеют эти маркеры только для удобства чтения). Он полагается на эти маркеры, чтобы предлагать функции вырезания и вставки для разработчиков. Back-end PHP-программисты могут копировать и вставлять эти регионы из шаблона (например, бумажные модели) и создавать с ним графические интерфейсы веб-сайтов и веб-приложений. Кроме того, у них очень удобный API. Например, чтобы разрезать такой регион:
<!-- cut:siteMenu --> <nav> <ul> <li>...</li> </ul> </nav> <!-- /cut:siteMenu -->
Они могут использовать объектно-ориентированную нотацию:
$template->getSiteMenu()->setLink( ... ); etc..
Я думаю, что это действительно круто.
Действительно, разделение и повторное использование являются ключевыми словами здесь.
Лучший способ разработать и сегментировать рабочую нагрузку в команде – это когда веб-дизайнер (интегратор / html-ist и т. Д.) Не имеет шансов сломать часть программирования (база данных, файлы, сеансы, синтаксические ошибки и т. Д. на).
Я рекомендую использовать FigDice Template Engine , который обеспечивает очень четкое разделение между Logics (программа, база данных, файлы, алгоритмы и т. Д.) И презентация (представления и информация, которые они представляют) в полной безопасности.
FigDice поддерживает, конечно, макросы (многоразовые части файла), включение, итерации и многие другие функции, а также обеспечивает эксклюзивный подход к разделению Presentation / Logics с инверсией управления поставщиками данных (Views вытягивают информацию, которую они должны отображать, вместо того, чтобы позволить контроллерам вставлять данные в шаблоны, как это обычно бывает практически с каждым движком шаблонов). Это позволяет дизайнеру HTML действительно решить, что он хочет представить, когда и как, без какого-либо риска разрушения кода.
Я был бы рад получить отзывы и комментарии. благодаря