Почему я должен использовать систему шаблонов в PHP?

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

Тем не менее , те же люди, у которых есть проблемы, разделяющие проблемы, в конечном итоге создают HTML-код и подают его на smarty или выполняют PHP-код в Smarty, поэтому Smarty вряд ли решает проблему разделения проблем.

Смотрите также:

• PHP как язык шаблонов или какой-либо другой скрипт шаблонов
• Каков наилучший способ вставки HTML через PHP?

Основная причина, по которой люди используют шаблонные системы, – это отделить логику от представления. Из этого вытекает несколько преимуществ.

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

Кроме того, разбивая страницу на отдельные файлы, как программист, так и дизайнер могут работать на одной и той же странице одновременно, проверяя исходный контроль по мере необходимости, без конфликтов. Дизайнеры могут тестировать свои шаблонные визуальные эффекты против стабильной версии кода, в то время как программист делает другие, потенциально нарушающие изменения, свою собственную копию. Но если бы эти люди редактировали один и тот же файл и должны были сменяться разными изменениями, вы можете столкнуться с проблемами.

Это также обеспечивает хорошую практику программирования, позволяя вести бизнес-логику от логики представления. Если вы примете свою бизнес-логику вместе с презентацией, вам будет сложнее извлечь ее, если вам нужно представить ее по-другому позже. В наши дни все более популярны различные способы представления в веб-приложениях: RSS / ATOM-каналы, ответы JSON или AJAX, WML для карманных устройств и т. Д. С помощью системы шаблонов это часто можно сделать полностью с помощью шаблона и без каких-либо изменений остальное.

Тем не менее, не все будут нуждаться в этих преимуществах. Преимущество PHP над Java / Python / Ruby / и т. Д. Заключается в том, что вы можете быстро взломать веб-страницы с некоторой логикой в ​​них, и все хорошо.

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

И если разработчик это понимает, система шаблонов является лишь ограничением. Он не добавляет никакой ценности процессу разработки, а только накладные расходы на изучение нового синтаксиса, обновление текущей библиотеки и более медленное выполнение. Хотя последнее можно решить с помощью кеширования и еще много чего, это только устраняет проблему, которая иначе не существовала бы. Таким образом, системы шаблонов не имеют никакой ценности, никаких преимуществ.

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

По-прежнему есть веская причина использовать систему шаблонов, но не Smarty, а PHPTAL . Шаблоны PHPTAL являются действительными файлами XML (и, следовательно, XHTML). Вы можете использовать фиктивный контент в PHPTAL и таким образом получить действительный файл XHTML с окончательным внешним видом, который может быть обработан и протестирован со стандартными инструментами. Вот небольшой пример:

 <table> <thead> <tr> <th>First Name</th> <th>Last Name</th> <th>Age</th> </tr> </thead> <tbody> <tr tal:repeat="users user"> <td tal:content="user/first_name">Max</td> <td tal:content="user/last_name">Mustermann</td> <td tal:content="user/age">29</td> </tr> </tbody> </table> 

Механизм шаблона PHPTAL автоматически вставляет все значения из массива пользователей и заменяет наши фиктивные значения. Тем не менее, таблица уже является действительной XHTML, которая может отображаться в браузере по вашему выбору.

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

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

В настоящее время flickr использует smarty. его не должно быть плохо, не так ли?

PHP – это в значительной степени система шаблонов. Ключ должен заставить себя самостоятельно отделять логику от презентации. Использование Smarty или что-то в этом роде делает немного более неудобным смешивать логику и презентацию. Если вы не можете самостоятельно разделить их самостоятельно, использование системы шаблонов не поможет. Все, что он собирается сделать, это съесть дополнительную вычислительную мощность.

Ключ состоит в том, чтобы не изменять какие-либо значения в коде презентации. Для этого я считаю, что сам PHP так же эффективен, как и Smarty, если вы используете синтаксис if / endif:

 <?php if($some_test): ?> <em>Some text!</em> <?php endif; ?> 

В основном я думаю, чтобы избежать какой-либо «небезопасной» логики бэкэнд для применения в шаблонах. Поскольку большинство шаблонов времени передаются дизайнерам, мы хотим только дать им закрытый набор вещей, которые они могут сделать.

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

 if (loggedIn) { // print lots of HTML here } else { // print error message } 

В Smarty это может быть что-то вроде этого (простите мой, вероятно, неправильный синтаксис, это было какое-то время):

 if (loggedIn) { $smarty->bind("info", someObject); $smarty->display("info.template"); } else $smarty->display("error.template"); 

Если бы вы были действительно умны, вы даже могли бы отображать шаблон страницы входа вместо шаблона ошибки, необязательно с сообщением, объясняющим, почему пользователь оказался там. И если вы пошли с техникой, как я ее написал, а затем решили, что вы хотите переключиться на отображение окна входа, это всего лишь одно изменение строки! Для меня речь идет не только о сохранении разделения взглядов и логики, но и о возможности повторного использования общих элементов представления из многих мест.

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

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

Вы дважды забыли htmlspecialchars() . Вот почему вам нужна система шаблонов.

Смарти плохо. Не судите о системах шаблонов, основанных на этом.

Ваш анализ является разумным. Я полагаю:

• Дизайнеры шаблонов и сторонние программисты могут быть не одинаковыми, поэтому они способствуют разделению.
• Он защищает вас от вас самих, в том смысле, что вы не можете делать «слишком много» PHP в своих шаблонах.
• Может быть проще оптимизировать / прекомпилировать шаблоны в некоторых сценариях? (Это предположение)

Лично я думаю, что они больше хлопот, чем они того стоят. В частности, они не работают, если вы хотите передать шаблоны «дизайнерам», поскольку инструменты WYSIWYG не знают, что с ними делать.

Одно из преимуществ механизма шаблонов, которое я не видел, – это возможность динамических элементов html – что-то вроде элементов управления asp.net. Например, с помощью HTML Template Flexy из PEAR вы можете иметь элементы динамической формы, которые автоматически сохраняют состояние. Регулярный элемент выбора html может быть заполнен и выбран выбранный элемент в коде позади без циклов или условных выражений в шаблоне.

Я думаю, что более чистый синтаксис – довольно большая победа. Хотя это может выглядеть только несколько символов, но когда вы делаете это каждый день, каждый персонаж начинает подсчитывать.

И {$myvar|escape} – IMHO, немного короче, чем <?php echo htmlspecialchars($myvar); ?> <?php echo htmlspecialchars($myvar); ?> . (Помните, что синтаксис <?=$foo?> Доступен, только если он специально включен в PHP conf.)

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

• Вы хотите использовать файл с PHP-кодом в качестве шаблона? Хорошо.
• Вы хотите использовать переменные в указанном шаблоне? Хорошо.

Просто не забудьте разделить логику и конечный результат (презентацию). Это лучше достигается с помощью шаблонов шаблонов. Но вам не нужно изучать что-то вроде Smarty.

• Если вы используете Zend_View или аналогичный, вы можете полностью использовать PHP-код.

У многих людей есть правильный ответ. Smarty не является шаблоном в PHP. Отнюдь не. Smarty существует в основном для тех, кто должен использовать дизайнеров (т.е. не программистов) для редактирования и настройки отображения страниц. Если все, кто собирается изменить макет ваших страниц, могут запрограммировать, вы можете пойти с более PHP-ориентированной системой шаблонов. Но вы действительно должны иметь все готовые выходные данные и отправить их в шаблон. Если вы позволяете каждой странице извлекать, обрабатывать и отображать контент, вам придется реорганизовать его раньше и позже.

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

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

И не будем забывать о будущем. Веб-сайты старые почти в тот момент, когда они публикуются. В какой-то момент вам нужно будет обновить внешний вид. Если вы поддерживаете разделение часто, как только дизайнер может завершить целый новый веб-сайт с тем же программированием на задней панели. Это позволяет выполнять более быструю и дешевую редизайн, позволяя задействовать программиста только в том случае, если требуется новая функциональность.

Некоторые могут утверждать, что Smarty делает то, что может сделать PHP: отделить презентацию от бизнес-логики. Язык программирования PHP отлично подходит для разработки кода, но при смешивании с HTML синтаксис операторов PHP может быть бесполезным для управления. Smarty восполняет это, изолируя PHP от презентации с помощью более простого синтаксиса на основе тегов. Теги показывают содержимое приложения, обеспечивая четкое разделение с кодом PHP (приложения). Для управления шаблонами Smarty не требуется знание PHP.

Важность этого разделения является ситуационной. Это обычно более важно для веб-дизайнеров, чем для разработчиков PHP. Поэтому Smarty обычно хорошо подходит, когда роли разработчиков и дизайнеров разделены. Нет правильного или неправильного ответа: каждая команда разработчиков имеет свои собственные предпочтения для управления кодом и шаблонами. Помимо синтаксиса на основе чистого тега, Smarty также предлагает широкий спектр инструментов для управления презентацией: гранулированное кэширование данных, наследование шаблонов и функциональная песочница, чтобы назвать несколько. Бизнес-требования и PHP-код Smarty используется с большой ролью в определении того, подходит ли Smarty.

Я бы сказал, что если язык шаблонов PHP был настолько принудительным, чтобы заставить вас его использовать, вы бы его вообще не использовали. Возможность «выпрыгивать» и делать что-то на своем пути, когда в беде является одним из привлекательных факторов PHP.

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

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

Я лично всегда использую шаблонизаторы в php, python или что-то еще.

Первая очевидная причина, о которой уже говорили другие:

Это заставляет вас не использовать бизнес-логику в ваших шаблонах.

Да, конечно, дисциплина будет прекрасна, когда у вас это будет.

Но это всего лишь крошечный аспект того, почему вы должны использовать шаблонный движок . Большинство из них больше, чем просто движок и могут считаться шаблонами шаблонов, нравится вам это или нет.

Например, Smarty также имеет расширенные функции кэширования, такие как частичное кэширование. Действительно полезный материал, вещи, которые вам придется делать самостоятельно, используя только php, как язык шаблонов.

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

Так что да, это вопрос выбора. Когда вы нуждаетесь в действительно простых шаблонах, подумайте о том, чтобы показать какую-то дисциплину, чтобы ваша логика не зависела от ваших шаблонов. Но когда вы ожидаете, что ваше приложение будет расти, в конечном итоге вам понадобятся функции шаблона. И к тому времени вы, надеюсь, не изобретаете колесо, кодируя все это.

И последнее, но не менее важное: для меня есть одна функция убийцы, доступная в некоторых шаблонах шаблонов.

Наследование шаблонов

Я узнал об этом из Django, и теперь я использую его в последнем Smarty 3 . Ребята из Symphony framework также имеют Twig , которые вы можете рассматривать порт с синтаксисом Django.

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

Для меня это хранитель!

система управления шаблонами, мы можем управлять файлами шаблонов отдельно. время выполнения системы будет быстрее, чем обычный PHP-проект. поэтому здесь файлы PHP и файлы шаблонов поддерживаются отдельно.

после запуска файлов код будет сохранен в файле template_c. поэтому он не компилируется много раз.

Я несколько раз использовал tinybutstrong , у которого довольно простой и простой синтаксис. В html-шаблоне нет циклов или псевдокодов.

На своей домашней странице:

TinyButStrong – это библиотека, которая позволяет динамически создавать страницы XML / HTML и любые другие файлы на основе источника текста. Это шаблонный механизм для языка PHP. Это позволяет вам легко отображать информацию из вашей базы данных, а также серьезно гармонизировать и упростить ваше программирование на PHP.

TinyButStrong ориентирован на HTML, но не специализируется на Html. Это означает, что он может работать с текстовыми файлами, XML, RSS, RTF, WML, Excel (xml), … Плагин OpenTBS позволяет объединять документы OpenOffice и Ms Office.

Разработчики, которые будут использовать концепции ООП в значительной степени, например, люди JAVA / Spring / Oracle PL-SQL, говорят, что сам язык PHP используется для представления / просмотра / отображения логики в проектах уровня предприятия. В этих BIG-проектах основой является Oracle, база данных извлекается с использованием pl-slq / java, а презентация – php. Лучший пример – facebook. http://en.wikipedia.org/wiki/Facebook facebook использует php для презентации, java / c ++ в качестве внутреннего интерфейса.

Единственная причина, по которой php используется как презентация, потому что она тесно работает с HTML, но java / c ++ больше основаны на OOP и не может быть напрямую привязана к HTML. Скажите мне одну CMS (joomla / drupal / wordpress) или фреймворк (zend / symfony / Yii), который использует Smarty? Итак, ПОЧЕМУ умный нужен?

Мне нравится использовать шаблоны по нескольким причинам:

1) Он очищает читаемость кода PHP. Мое PHP-файлы становятся раздутыми и непримиримыми, когда есть печатные ("") операторы с кусками HTML везде. Кроме того, возникают проблемы, как передать переменные в текст HTML? Вы используете везде везде? Используете ли вы печать ("") и избегаете своих котировок HTML и объединяете свои переменные? Используете ли вы печать ("") и используете одинарные кавычки в HTML, действуя против стандарта, и вставляете свои переменные напрямую?

2) Он очищает представление HTML-кода. Может быть трудно сохранить ваш сгенерированный HTML, выглядящий хорошо, если он разрезан и взломан на несколько файлов. Например, ваш отступы могут уйти.

3) Он позволяет создавать несколько шаблонов, а затем пользователь, зарегистрированный в системе, может выбрать, какой шаблон / скин он хочет отображать при просмотре вашего веб-сайта, а также вы можете быстро и без особых усилий изменить шаблон по умолчанию на что-то еще, если вы так склонны.

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