кументов не имеют в принципе никакого 
расширения? Например, мы хотим хранить рисунки GIF, JPG и PNG в файлах 
без расширения. Разумеется, в этом случае директива AddType нам не помо-

Глава 29. Модульность программы. Написание "библиотекаря" 
413 
жет. Однако у Apache существует еще одно мощное средство для распознава- 
ния типов страниц — это модуль mod_mime_magic (конечно, если он подклю- 
чен к той версии сервера, которая установлена у вашего хостинг-провайдера). 
В случае, если определение типа на основе директив AddType закончилось 
неудачей, этот модуль пытается по нескольким первым байтам файла узнать, 
какого же он типа. Например, во всех GIF-файлах первые три байта — симво- 
лы G, I и F. Поэтому с вероятностью практически 100% определение типа про- 
ходит правильно. 
Предположим, что мы хотим связать расширение php4 с PHP для всего сайта. Для 
этого запишем в файл .htaccess, расположенный в корневом каталоге сервера, та- 
кую директиву: 
AddType application/x-httpd-php php4 
Теперь для всех файлов с расширением php4 будет выполняться то же, что и для 
php. 
Кстати говоря, именно такая директива (но для php) записана в главном файле 
httpd.conf вашего хостинг-провайдера. 
Решение проблемы 
зацикливания обработчика 
Помните, обработчик из листинга 29.5 мы связали только с расширениями html и 
htm, но не php? Мы сделали это, чтобы избежать зацикливания обработчика (см. 
со- 
ответствующее замечание). Давайте исправим положение. Очевидно, нужно свя- 
зать с PHP еще одно расширение, которое не будет использоваться в сайте нигде, 
кроме как в имени обработчика из листинга 29.5. Пусть это будет, например, php4.
 
Модифицируем наш .htaccess: 
# Связываем расширение php4 с PHP 
AddType application/x-httpd-php php4 
# Замкнем имя обработчика на конкретный файл 
Action libhandler "/lib/libhandler.php4?" 
# Документы этого типа мы желаем "пропускать" через наш обработчик 
AddHandler libhandler .html .htm .php 
Ну и, конечно, осталось только переименовать имеющийся у нас файл 
libhandler.php в libhandler.php4. 
Теперь все сценарии с расширением php могут использовать функции, предоставляе- 

мые библиотекарем. 


Глава 30 
Код и шаблон 
страницы 
Что и говорить, конечно, очень удобно, что PHP позволяет комбинировать код про- 

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

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

от текста, задающего внешний вид страницы. А именно — хранить их в разных фай- 
лах. Я уже неоднократно затрагивал такой подход в этой книге, все время 
ссылаясь 
(не совсем явно) на настоящую главу. Что же, теперь настало время по 
достоинству 
оценить тот выигрыш, который дает нам отделение кода от шаблона страницы. 
Думаете, сейчас мы будем углубляться в "дебри теории", далекой от практики и 
вряд 
ли вам полезной? Ничего подобного. Я просто расскажу, как можно удобно строить 
свои программы, а в конце приведу довольно "внушительный" код шаблонизатора 
(так я называю систему управления страницами и шаблонами), который призван сде- 

лать работу Web-программиста максимально простой и эффективной. 
Некоторые программисты утверждают, что отделению кода от шаблона стра- 
ницы уделяют слишком много внимания — чрезмерно много. Если и вы так 
думаете, — что же, я не буду с вами спорить и критиковать вашу точку зрения. 
Если бы я не занимался этой проблемой столько времени, то, возможно, и сам 
бы так считал. Будем честны: отвечает ли проблема отделения кода от шабло- 
на страницы тому вниманию и количеству страниц, что я ей здесь уделил? От- 
кровенно говоря, не отвечает. В действительности, чтобы