Шаблон страницы

Генератор данных

Интерфейсная часть программы

"Т

Ядро

Конфигурация

Рис. 30.2. Трехуровневая схема

Интерфейс

Как можно заметить из листинга 30.4, интерфейс сценария гостевой книги стал гораздо проще, чем это было с генератором данных из листинга 30.2. Файл, в котором содержится его код, называется точно так же, как и файл генератора. Это и не удивительно: "снаружи" интерфейс выглядит как полноценный генератор данных, а о существовании ядра шаблон даже и не "подозревает".

Листинг 30.4. Интерфейс: gbook.php

<?

include "kernel.php"; Загружаем ядро. $Book=LoadBook(GBook); Загрузка гостевой книги. Обработка форм:, если сценарий запущен через нее. if(!empty($doAdd)) {

Добавить в книгу запись пользователя.

$Book=array(time()=>$New)+$Book;

Записать книгу на диск.

SaveBook(GBook,$Book);

Загрузка шаблона не нужна выз1вает интерфейс.

теперь, наоборот, шаблон

?>

Как видим, интерфейс занимается только той работой, для которой он и предназначен: выступает "посредником" между ядром и шаблоном. Самым первым загружается ядро - файл kernel.php (я люблю так его называть). Дальше осуществляется исключительно обработка и "расшифровка" входных данных и формирование выходных.

Ядро

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

Ядро в идеале должно содержать лишь набор функций, которые позволяют исчерпывающим образом работать с объектом программы. В этом смысле идеально его объектно-ориентированное построение. Об объектно-ориентированном программировании на PHP будет вкратце рассказано в главе 31, а пока не будем усложнять и без того " скользкую" задачу и посмотрим, что представляет собой ядро нашей гостевой книги (листинг 30.5).

i Листинг 30.5. Ядро: kernel.php

<?

Загружаем конфигурацию. include "config.php";

Загружает гостевую книгу с диска. Возвращает содержимое книги.

function LoadBook($fname)

{ $f=@fopen("gbook.dat","rb");

if(!$f) return array();

$Book=Unserialize(fread($f,100000));

fclose($f);

return $Book;

Сохраняет данные книги на диске. function SaveBook($fname,$Book) { $f=fopen("gbook.dat","wb"); fwrite($f,Serialize($Book));

fclose($f);

?>

Проверка корректности входных данных

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

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

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

Действительно, здесь нет ничего, кроме определений функций и еще одной инструкции include (вздохните с облегчением - на этот раз последней). Она добавляет конфигурационные данные нашей книги - всего лишь одну-единственную константу GBook, определяющую имя файла, в котором гоствевая книга и будет храниться. "Для порядка" приведу и его (листинг 30.6).

! Листинг 30.6. Конфигурация: config.php

<?

define("GBook","gbook.dat"); имя файла с данн1ми книги ?>

Примечание

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