| |
рались до смысла "этого сладкого слова" — шаблонизатора, которое я
применяю то тут, то там по всему тексту. Возможно, чуть разобравшись в
прилагае-
мом исходном коде, а затем и опробовав программу на практике (наверное, перепи-
сав на свой лад), вы разделите мое убеждение о том, что хороший шаблонизатор
мо-
жет сэкономить студии немало лишних часов работы.
Выше я описал недостатки двухуровневой схемы и показал, как их можно преодолеть
при помощи трехуровневой модели построения сложных сценариев. Но, если вы пом-
ните, одна задача так и осталась нерешенной.
А именно, мы обратили внимание, что даже при использовании трехуровневой схемы
мы не можем легко менять внешний вид многих страниц сразу — без утомительного
изменения шаблонов каждой из них. Если вы не забыли, решение с включаемыми
файлами (в каждом из которых содержится отдельный, общий для всех сценариев
блок страницы) также нам не подходит, потому что оно лишь слегка меняет поста-
Часть V. Приемы программирования на PHP 430
новку проблемы редизайна. Даже используя инструкцию include, мы попадем в
тупик, если захотим изменить положения некоторых блоков на странице.
В общем, при всех достоинствах трехуровневой модели построения сценария ее
необ-
ходимо несколько видоизменить, чтобы добиться хотя бы минимальных удобств. Это
"видоизменение" я и называю шаблонизатором.
Термин "шаблонизатор" произошел от слова "шаблон" и не является стандарт-
ным для технической литературы. В этой книге я применяю его на свой страх и
риск и в основном из соображений краткости: писать везде (а вам — читать)
слова "система управления шаблонами" весьма утомительно.
Сама идея шаблонизатора не является новой в Web-программировании. Скорее даже
наоборот: существуют десятки систем, построенных по описанным ниже принципам.
Большинство из них — коммерческие и часто довольно сложны. В то же время мно-
гие свободно распространяемые системы (во всяком случае, те, с которыми я зна-
ком, — например, Mason, лебедевский Parser и др.) отличаются одним недостатком:
синтаксис их языка излишне сложен, а потому отпугивает. Кроме того, часто для
ос-
воения этих шаблонизаторов требуются навыки не только дизайнера или HTML-
верстальщика, но и программиста. Мы же, напомню в очередной раз, стремимся к
тому, чтобы распределить разработку сценария по возможно большему числу незави-
симых людей, многие из которых не знакомы с программированием.
Высказанные только что суждения являются моей личной позицией в вопросе
шаблонизаторов, а потому, как и все субъективное, они вполне могут несколь-
ко отличаться от действительности. Читателю предлагается самому их прове-
рить после того, как он ознакомится с моделью шаблонизатора, предлагаемого
в этой главе. Нужно заметить, что, конечно, каждая Web-студия считает свою
собственную версию шаблонизатора самой лучшей в мире.
Традиционное построение страниц
Итак, сосредоточим все свое внимание на том, как желательно строить сценарии,
чтобы максимально упростить проблему редизайна, а вместе с ней — добавление
новых страниц в карту сервера. Многие программисты ограничиваются тем, что раз-
бивают свои страницы на 3 логических блока: верхнюю часть (header), центральную
часть (text) и нижний участок страницы (footer). Каждая из этих составляющих
хра-
нится в отдельном файле. Центральный блок (text) является главным: до начала
рабо-
ты он загружает из файла общую для всех страниц верхнюю часть, а в конце
выводит
Глава 30. Код и шаблон страницы 431
нижнюю. Вот как примерно выглядит шаблон страницы при такой структуре сцена-
рия (листинг 30.7):
Листинг 30.7. Традиционное построение шаблона
Здесь идет главный текст страницы,
возможно, включающий данные,
сгенерированные интерфейсом Interface.php
Предполагается, что файлы header.htm и footer.htm хранятся в подкаталоге
/templ корневого каталога сервера и содержат участки страниц, которые должны
быть выведены до и после основного текста страницы. Если сайт небольшой и в нем
используется не так уж много различных шаблонов страниц, данное решение являет-
ся самым простым. В таких ситуациях его применение оправдано. Но нас интересует
оформление больших и сложных сайтов. Предположим, наш ресурс содержит сотни
страниц, построенных по описанной схеме. Давайте взглянем на проблему с этой
по-
зиции.
Сложность перестановки блоков
Первый недостаток увидеть легко: мы не можем ни добавить новый блок в страницу,
ни изменить положения уже имеющихся. Если мы попытаемся это сделать, потребу-
ется менять код сотен страниц сайта.
Необходимо заметить, что в нашем примере вряд ли придется когда-нибудь
изменять порядок следования блоков, раз мы договорились рассматривать
проблему с общих позиций, а не с частных.
"Расщепление" шаблона
Второй недостаток более очевиден для дизайнера: файлы header.htm и
footer.htm, хотя и представляют собой логически один шаблон, все же разделены.
Все мы привыкли к тому, что многие тэги HTML (такие как ,
|
