| |
причем расположенные в том же самом файле. Но в
ситуации с разделением шаблона на footer и header мы, наоборот, должны хранить
большинство открывающих тэгов в одном файле, а закрывающие — в другом. В лис-
тинге 30.8 приведен пример верхней части шаблона страницы.
Часть V. Приемы программирования на PHP 432
Листинг 30.8. Файл header.htm
Добрый день.
| Карта раздела: . . . |
Видите, файл оборвался на открывающем тэге. Теперь взглянем на листинг 30.9:
Листинг 30.9. Файл footer.htm
|
Он состоит исключительно из одних закрывающих тэгов. Потенциально, добавив в
header.htm новый открывающий тэг, мы можем забыть закрыть его в footer.htm.
Кроме того, такая конструкция несколько противоречит логике: две похожих по
смыслу части шаблона содержатся в разных файлах. Мы уже обсуждали это выше и
пришли к выводу, что данное построение оказывается довольно неудобным.
Сложность смены шаблона у части страниц
Еще один недостаток описанной схемы следует из предыдущего. Каждая страница
должна "знать", где расположены файлы header.htm и footer.htm. Пусть у нас на
сайте есть каталог, в котором "лежат" сотни файлов. Во время разработки
оказалось,
что шаблон для всех файлов в этом каталоге должен отличаться от шаблона всех
ос-
тальных страниц (которых также немало). Значит, требуется создать еще одну пару
header- и footer-файлов, назвав их, например, header1.htm и footer1.htm. Это в
общем-то не представляет особой проблемы, сложность в другом: придется заменять
ссылки во всех файлах каталога. Можно, конечно, сделать это посредством
глобаль-
ных поиска и замены при помощи какого-нибудь текстового редактора (например,
HomeSite фирмы Allaire), но, согласитесь, это решение выглядит как явно
"лобовое".
Кроме того, если мы имеем доступ к сайту только с использованием FTP, нам при-
дется "скачивать" все страницы, редактировать их, а затем опять копировать на
сер-
вер. Естественно, для крупных информационных сайтов такие "накладные расходы"
просто неприемлемы.
Возможно единственное решение этой проблемы — заставить страницы "наследо-
вать" ссылку на шаблон каталога (или его родительского каталога), в котором они
Глава 30. Код и шаблон страницы 433
находятся. Таким образом, поправив эту ссылку в информации о каталоге, мы авто-
матически изменим шаблон и у всех страниц в нем.
Для сравнительно небольших систем все же существует путь, обходящий, хоть
и не очень удачно, рассматриваемую проблему. А именно, можно для каждого
раздела сайта использовать отдельную пару header- и footer-файлов. В дейст-
вительности же эти файлы будут представлять собой лишь символические
ссылки на "настоящие" шаблоны. Правда, эта схема работает лишь в системах
Unix. Кроме того, она нисколько не упрощает ситуацию, когда разработчики
решили перенести часть страниц из одного раздела в другой (сменив при этом
их шаблоны).
Что такое шаблонизатор?
Итак, мы вновь столкнулись с множеством трудноразрешимых накладок (возможно,
выглядящих для многих с первого взгляда как надуманные). Когда же они закончат-
ся, спросите вы? Отвечаю: прямо сейчас.
Давайте взглянем "в корень" описанных выше сложностей. Почему они вообще воз-
никают в этой задаче? Нетрудно догадаться: опять же из-за излишних зависимостей
данных. Помните, эти зависимости привели нас в свое время к необходимости пере-
хода от двухуровневой схемы построения сценариев к трехуровневой? Теперь они
подводят нас к идее шаблонизатора.
Вспомним, что мы сделали тогда, чтобы убрать зависимости. Мы поменяли местами
"поставщика" и "исполнителя". Идея выполнить обратную перестановку кажется аб-
сурдной, т. к. мы опять придем к тому, с чего начали. Конечно, мы не будем так
де-
лать. Зададимся отвлеченным вопросом: что предпринимает общество, когда перед
ним возникает чересчур большое количество нерешенных и необъяснимых задач?
Оно придумывает себе богов. В программировании — то же самое. Раз мы не можем
больше сослаться ни на генератор данных, ни на шаблон, значит, настало время
реа-
лизовать нечто третье, "бога", управляющего всей системой в совокупности и
распре-
деляющего
|
|
