Шаблоны tpl php как использовать. Использование tpl-файлов. Содержимое страницы по умолчанию

Дорогие друзья,

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

Итак первое что нам необходимо это обратится к документации скрипта, которая гласит что шаблон main.tpl поддерживает следующие теги:

Текст который выводит текст заключенный в теги если просматривается указанный раздел сайта

также у этого тега есть противоположность

Текст который выводит текст заключенный в теги если просматривается любой раздел кроме указанного

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

Тут весь текст шаблона, который будет показываться при просмотре обратной связи
тут весь текст шаблона, который будет показываться везде кроме обратной связи

Но у этого есть один большой минус, ваш основной файл шаблона main.tpl будет слишком большого размера, т.к. по сути будет содержать два разных оформления, и тут мы опять обращаемся к документации и скрипта и узнаем о существовании прекрасного тега: {include file="my_block.tpl"} , который подключает указанный файл my_block.tpl в шаблон.

Исходя из всего выше изложенного финальная реализация выглядит следующим образом:

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

С уважением,

Сразу скажу, что я уже писал об этой теме здесь: . Однако, не все поняли данный материал, и я решил к нему вернуться и написать всё немного по-другому. Не секрет, что любой серьёзный движок никогда не будет смешивать в своём коде HTML и PHP . Однако, HTML и PHP коды очень тесно взаимосвязаны, поэтому для того, чтобы не нарушать правила "хорошего тона", были придуманы tpl-файлы . Данные файлы служат для хранения HTML-кода с элементами шаблонов , которые подставляются в PHP-коде . Давайте подробнее разберём использование tpl-файлов с примером.

Возьмём с Вами самый элементарный пример - это панель пользователя, где есть его аватарка и приветствие по имени. Первым делом, создадим tpl-файл , и пусть он называется userpanel.tpl . Напоминаю, что это всего лишь кусок HTML-кода с элементами шаблона :

Здравствуйте, %name%!

Ничего сложного, это просто обычный HTML-код . Только вместо определённых значений стоят %элементы_шаблона% .

Теперь разберёмся с PHP-обработкой . Здесь всё будет более, чем абстрактно, но, к сожалению, по-другому никак. Главное - это понять принцип работы. И так PHP-код для обработки созданного tpl-файла :

Это простейший вариант. Всё прокомментировано, поэтому вопросов по этому примеру возникнуть не должно. И по сути любая страница состоит из таких вот блоков. Ваша задача взять нужные блоки (функция getTemplate() ), заменить нужными данными (функция str_replace() и данные полученные, например, из базы), а потом просто соединить все блоки, как обычные строки, и вывести всё на страницу.

Безусловно, без ООП здесь очень проблемно будет. Вы такое количество условий наплодите (страниц же много), что быстро запутаетесь. Но принцип использования tpl-файлов , надеюсь, Вы осознали. Дальше уже самостоятельно подумайте, как всё это обернуть в ООП , чтобы всё было максимально простым с точки зрения понимания кода и его сопровождения в будущем.

Отделение логики получения данных от логики их отображения - очень важная составляющая веб-девелопмента.
Любой программист, который поднялся чуть выше уровня "Hello world", начинает ощущать потребность в таком разделении. Но далеко не все приходят к правильным выводам и решениям.
Поэтому я приведу здесь самые важные правила:
1. Код получения и код отображения данных надо разделять.
2. Любой вывод должен начинаться только после того, как для него готовы все данные.
3. Как следствие, любой скрипт должен заниматься только обработкой данных. После этого он может либо отправить какой-то НТТР заголовок, или вызвать шаблон, передав ему подготовленные данные, или и то и другое вместе.
4. Каким именно шаблонизатором пользоваться - дело десятое. Самый простой и доступный - сам РНР, поэтому примеры будет приводиться на нём.

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

Самое простое и очевидное заблуждение состоит в том, что новички называют шаблоном вынесенный в отдельный файл "дизайн" - общий html для всех страниц сайта. И на этом успокаиваются. Динамическую информацию, ничтоже сумняшеся, выводя старым добрым echo:-)
На самом же деле, шаблонизатор в основном занимается выводом изменяющегося содержимого страниц сайта. А вывод "дизайна" - задача второстепенная.

Фантазий же главных две:
1. Шаблоны нужны "дизайнеру", чтобы он мог их править, не разбираясь в PHP.
2. Следовательно, шаблоны служат для отделения PHP от HTML.

Давайте попробуем задуматься над первым утверждением. Кто такой дизайнер? Это человек, который работает в фотошопе. HTML он чаще всего не знает вообще. А над шаблоном работает либо специальный верстальщик или - чаще всего... сам программист! Смешно, правда?
Теперь следствие, про отделение PHP от HTML. Отлично. Перед нами стоит святая цель отделить. Поэтому мы придумываем Смарти и пишем:
{foreach key=cid item=con from=$contacts}
{$con.name} - {$con.nick}

{/foreach}
Ещё смешнее.
"Дизайнер", ради которого все затевалось, падает в обморок от счастья.

Теория
Получается, что наши причины, по которым мы решили пользоваться шаблонами, гроша выеденного не стоят. И что же теперь - не нужны, выходит, шабоны вообще? Нужны. Но сначала надо ответить себе на вопрос - "зачем?" Для чего нужны шаблоны. И проверить ответ практикой. Я много раз задавал людям этот вопрос. Но почти никто не может на него ответить. Зачем ему нужны шаблоны. Получается, люди делают что-то, не зная зачем.
Это - самое смешное.

За время своей деятельности в качестве веб-программиста я сформулировал для себя три причины, по которым нужны шаблоны лично мне. По сути, их две. А сводятся, в конечном счете, к одной:

Один код - несколько представлений .

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

Часто одну и ту же информацию надо показывать в нескольких видах. К примеру - обычная страница и страница для печати. Информация та же самая, код её получения один и тот же, а код вывода - разный. Столкнувшись с такой ситуацией, очень быстро разделишь свой код на две части, одна из которых отвечает за вывод, а вторая - не отвечает. Еще пример: допустим, нам захотелось выводить информацию не напрямую в HTML, а через AJAX-запрос, в формате JSON. Если у нас использовался шаблонизатор, то мы меняем в нашем коде ровно одну строчку - вызов шаблонизатора на вызов json_encode() . А если бы у нас вывод был перемешан с кодом получения данных, то код бы пришлось переписывать весь!

В чем-то похожая ситуация: допустим, наш скрипт стоит на двух сайтах. Плюс копия у нас дома. И вот дома мы нашли крупную багу. Заделали её. Теперь надо обновить код на сайтах. И вот он - момент истины: если шаблоны были использованы правильно, то мы просто заливаем код на оба сайта, и все продолжает работать, как ни в чем не бывало! Такая ситуация, как я считаю - идеальная проверка выбранного подхода к шаблонизации.

Ещё один важный момент, который многие упускают (в своих теоретических рассуждениях, при этом постоянно сталкиваясь с ним на практике!) - порядок выполнения скрипта не всегда совпадает с порядком вывода в шаблоне . Хрестоматийный пример - вывод заголовка статьи в теге . Если мы выводим информацию по мере поступления, то просто не сможем этого сделать - шапка сайта уже выведена, к моменту, когда мы начали получать текст новости.

Следует также помнить, что кроме текста РНР скрипты еще и выводят HTTP заголовки. Которые обязаны выводиться до любого текста, или даже вместо текста вообще (если мы например хотим перенаправить пользователя на другую страницу). Если мы сначала реализуем логику работы приложения, ничего не выводя при этом, то выдать нужный НТТР заголовок не составит для нас никакой проблемы.

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

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

Сам файл links.php. НИЧЕГО не выводит. Только готовит данные и после этого вызывает шаблон.

В нужном месте в него включается шaблон нашей страницы (tpl_links.php):

• " />