еделяющую имя файла, в котором гоствевая книга и будет храниться. 
"Для порядка" приведу и его (листинг 30.6). 
Листинг 30.6. Конфигурация: config.php 
 
Что же у нас получилось в результате? Мы "растянули" простой сценарий на 
целых 5 файлов (если считать еще и .htaccess, то на 6). Что ж, если вы так 
думаете, я с вами соглашусь. Тут все дело в том, что для простых сценариев 
(а именно такой мы и рассматривали) трехуровневая схема построения оказы- 
вается чересчур уж "тяжеловесной". Про такую ситуацию в народе говорят: "из 
пушки по воробьям". Что же касается сложных систем, не следует забывать, 
что "единственность" ядра может сэкономить нам количество файлов, если у 
комплекса много различных интерфейсов (например, разветвленная система 
администрирования), не говоря уже о простоте отладки и поддержки. Кроме то- 
го, можно полностью разделить работу по написанию ядра и интерфейса меж- 
ду несколькими людьми. 
Проверка корректности входных данных 
До сих пор мы не заботились о том, корректные ли данные заносит посетитель. В 
на- 
шей ситуации это и не нужно: в книгу кто угодно может добавлять любую информа- 
цию. В то же время в реальной жизни, конечно, приходится проверять правильность 

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

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

Глава 30. Код и шаблон страницы 429 
Интерфейс должен сгенерировать сообщение и передать его шаблону. Последний, 
"заметив" сообщение, может вывести текст контрастными буквами, например, вверху 

страницы. С этим никаких проблем быть не должно. Пусть интерфейс в случае ошиб- 

ки создает переменную $Error и присваивает ей текст ошибки. Вот как может вы- 
глядеть шаблон: 
. . . 
 
Произошла ошибка: 
 
 
. . . 
Такой подход, хоть и прост, оказывается немного неудобным для пользовате- 
ля. Действительно, ему сообщают, что произошла ошибка, но не говорят, на- 
пример, какое именно поле формы он заполнил неправильно. Пользователь 
желает, чтобы сообщения об ошибках появлялись напротив неверно введен- 
ных данных. К сожалению, без дополнительного программирования в шаблоне 
на PHP этого добиться довольно сложно (если вообще возможно). Единствен- 
ный имеющийся выход — использовать шаблонизатор и написать для него 
фильтр (функцию, занимающуюся финальной обработкой блока страницы 
перед ее отправкой), которая будет в автоматическом режиме рядом со всеми 
тэгами формы проставлять возможные сообщения об ошибках (а заодно и ат- 
рибуты value в самих тэгах, чтобы поля формы сохраняли свои значения ме- 
жду вызовами сценария). Эта задача, пожалуй, потребует всей информации о 
PHP, заложенной в этой книге, и еще, вероятно, хорошего знания регулярных 
выражений Perl. Код, полностью решающий проблему, слишком объемен, что- 
бы уместиться на страницах данной книги. 
Шаблонизатор 
Вот мы и до