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

Поехали!

Начнем с начала. То есть, надо определить рабочие переменные в class_init. Уже сейчас нам потребуются:

');?>

Полагаю, комментировать тут нечего. Недостающие у вас директории - создайте.

Обращение: если вы достаточно хорошо владеете английским языком, не откажите в помощи - необходимо создать англоязычную версию сайта slang.ru: тексты в дизайне, сообщения об ошибках, тексты для рассылок. А то я с этим на должном уровне не справлюсь. Спасибо всем, кто откликнется!

Мы к этому файлу еще ни раз вернемся, чтобы добавить полезных переменных и констант.

Теперь давайте разберемся с базой данных. Вернее, с подключением к ней и с оформлением sql-запросов. Класс class_mysql:

sql_conn_id=@mysql_pconnect($this->sql_host,$this->sql_user,$this->sql_pass); if(!$this->sql_conn_id) return(111); // ошибка подключения к базе данных if(!@mysql_select_db($this->sql_db)) return(113); // ошибка выбора базы данных return(0); } ?>');?>

Зачем я вынес реквизиты подключения в отдельные переменные, когда обычно их прописывают в mysql_connect сразу? Я это сделал для того, чтобы иметь возможность переопределить их в нужный момент. Например, если в URL-запросе какой-то из brain-ов определит, что надо подключиться к другой базе данных, то достаточно будет переопределить некоторые из перечисленных переменных, чтобы вся система начала работать с другой базой данных, находящейся на любом другом компьютере Интернета.

Примечание: использовать для подключения к SQL-базе функцию mysql_connect() или mysql_pconnect() - решайте для себя сами. Лично мне кажется, что логичнее использовать функцию mysql_pconnect() по причине того, что она сначала пытается установить постоянное соединение, а потом обычное, если постоянное создать не удалось. В этом есть известное удобство. В принципе, можно в список глобальных mysql-переменных добавить еще одну - указывающую тип подключения, чтобы можно было динамически ею управлять, но сейчас я в этом не вижу большого смысла, поэтому делать этого пока не буду.

К строкам:

conn_id) return(111); // ошибка подключения к базе данных и return(0); ?>');?>

привыкайте сразу, такие строки будут попадаться нам в каждой функции, и не по одному разу. Смысл их прост - функция возвращает код ошибки. Если возвращен "0", то функция отработала без ошибок. Если возвращен не "0", значит, произошла ошибка, код которой необходимо обработать.

Так сложилось, что ошибка подключения к базе данных у меня всегда или "11" или "111", так зачем же мне отступать от своих привычек?

Пишу в файл /info/errors.txt:

; ошибки SQL
111	не удалось подключиться к базе данных SQL

Первая строка - это комментарий. Рекомендую все ошибки разбивать на логические группы и комментировать эти группы: ошибки sql, ошибки работы с файлами, ошибки авторизации и так дальше. Если вы помните, в нашем файле описания ошибок комментарием считается любая строка, начинающаяся НЕ с цифры.

В class_init мы определили переменную $debug_level. Она указывает движку максимальный номер ошибки, ниже которого все другие считаются критическими, и о них следует докладывать администратору сайта. Поэтому располагать ошибки мы будем по мере их критичности: чем меньше номер ошибки, тем важнее событие. Давайте сразу запишем в errors.txt следующие группы:

; 1-100 критические ошибки разного характера

; 101-200 ошибки SQL
111	не удалось подключиться к базе данных SQL

; 201-300 ошибки работы с файлами и деркториями

; 1000-2000 ошибки пользователей при работе с сайтом

Примерно так.

Дальше можно дробить выделенные диапазоны на более мелкие группы ошибок. Это уже по желанию.

Сейчас $debug_level установлен в 100000, поэтому отчеты о любых ошибках будут доставляться администраторам на перечисленные email-адреса в массиве $email_support.

Но вернемся к class_mysql. Нам необходимо создать еще несколько sql-функций.

sql_conn_id) // подключаемся к базе данных { $err=$this->sql_connect(); if($err) return($err); } // запрос $this->sql_res=mysql_query($this->sql_query,$this->sql_conn_id); // обработка ошибок $this->sql_errno=mysql_errno($this->sql_conn_id); if($this->sql_errno) { $this->sql_err=mysql_error($this->sql_conn_id); return(112); } return(0); } ?>');?>

Эта функция выполняет sql запрос и возвращает "0", если все удачно или код 112 - ошибка SQL-запроса (добавляем этот код в errors.txt).

Обратите внимание на то, что подключаться к базе мы будем именно из этой функции. Чтобы не следить в коде программы за своевременным подключением к SQL, мы проверяем идентификатор подключения $sql_conn_id, и если тот оказывается пустым, производим попытку подключиться к SQL.

Уже можно видеть механизм передачи кода ошибки по цепочке. Если ошибка произошла при подключении к базе (код 111), то он будет возвращен и функцией sql_execute() как 111. То есть пользователь и администратор узнают истинную причину возникшей ошибки, не взирая на название функции, возвратившей ошибку.

Чтобы упростить вызов sql_execute(), избавившись от необходимости заранее присваивать переменной $sql_query значения, сделаем функцию-наследника:

sql_query=$query; $err=$this->sql_execute(); if($err) return($err); return(0); } ?>');?>

Кто-то из вас спросит: "а почему бы сразу не сделать одну sql_run?", - отвечаю - затем, что случаи разные бывают. Если в процессе написания программы нам функция sql_execute() никак не пригодится, мы ее купируем.

Ну и...

sql_conn_id) @mysql_close($this->sql_conn_id); return(0); } ?>');?>

Надеюсь, тут пояснять нечего, да и вызывать мы эту функцию будем весьма редко, так как при persistent connection (mysql_pconnect) она не производит закрытия соединения, а при обычном соединении закрытие sql-соединения производится автоматически, когда скрипт завершает свою работу.

Примечание: Если вы не знаете, символ "@" используется для блокирования вывода всевозможных предупреждений в стандартный output, на экран или в браузер, проще говоря. Мы сами анализируем все возможные ошибки, поэтому дополнительная информация от php-интерпретатора в браузере - нам без надобности.

Ну вот, собственно, sql-класс готов, можно его использовать в бою. Шагаем дальше!





[шаг назад] [печатать] [в начало сайта]