Собственные страницы ошибок сервера Apache

Для начала немного теории. Всё, что написано ниже, справедливо для сервера Apache (их в интернете подавляющее большинство). Когда вы набираете в строке несуществующий адрес или переходите по “битой ссылке”, на страничке высвечивается жирными буквами сообщение “Not found” - “документ не найден”, хотя вкупе с устрашающим видом надписи может быть переведено неопытным пользователем как “пошёл вон” :). Кстати, пользователи IE возможно и не видели эту страничку ни разу, поскольку он – IE – формирует в этом случае своё сообщение с “дружественным” содержанием, типа “обновите страничку, позвоните другу, который вам эту ссылочку дал…”, но это делу не помогает. Иногда IE может и показать оригинальное сообщение сервера, но только в том случае, если оно больше определённого размера (по умолчанию 512 байт). В общем, итог всегда один – страницы нет и посетитель недоволен. А нам, администраторам сайтов, надо заботиться, чтобы эта потеря была менее болезненной.

Давайте разберёмся, что происходит на сервере при запросе правильных/ошибочных URL.

При GET-запросе URL (тот, что в адресной строке браузера) передаётся серверу, а на выходе клиенту выдаётся набор заголовков с последующим полем данных. Заголовки никогда не выводятся пользователю напрямую и содержат много служебной информации, которая может быть обработан CGI-скриптами (а это нам скоро и понадобится). Среди этих заголовков всегда есть так называемые коды ответов. Если не вдаваться в подробности, то они передаются примерно так:
GET /index.htm
HTTP/1.1 404 Not Found

Первая строка говорит о том, что пользователем (точнее, браузером пользователя) был передан запрос на страницу index.htm, а вторая строка сообщает ему, что такой документ не найден, после чего следует блок данных - HTML-страница с сообщением об ошибке. Если URL правильный, всё происходит так, как и должно быть – передаётся код ответа 200 и запрошенный файл. Код ответа 200 передаётся всегда при удачном запросе, но мы его никогда не видим. Как уже говорилось, при неудачном запросе сервер сгенерирует код ответа в диапазоне 400…499 и мы увидим стандартное сообщение об ошибке, которое, огорчает пользователя и портит репутацию сайта. Вообще говоря, у хорошего веб-мастера таких ошибок на сайте быть не должно, но не его вина, что например пользователь вдруг сказал “принеси то, не знаю что”.

Перейдём от рассуждений к делу. У сервера Apache имеется стандартная директива обработки ошибок ErrorDocument, которая сопоставляет коду ошибки адрес документа, который будет показан пользователю. Обычно перенаправление устанавливают на документ, содержащий логотип сайта и краткую информацию “что делать”. Увидев такую страницу вместо стандартного сообщения на fatal.ru (два года назад, когда начал заниматься веб-программированием), я долго был под впечатлением! Откуда они знают, что у меня такой страницы нет? Формат директивы такой:
ErrorDocument 400 400.html

В случае ошибки 400 пользователю выдаётся файл 400.html – всё очень просто и удобно. Сразу же отметим, что можно использовать четыре варианта передачи сообщения об ошибке:
ErrorDocument 500 http://foo.example.com/cgi-bin/tester
ErrorDocument 404 /cgi-bin/bad_urls.pl
ErrorDocument 401 /subscription_info.html
ErrorDocument 403 “Доступ запрещён

В последнем случае вместо файла пользователь увидит на экране сообщение, следующее за одиночной кавычкой (закрывать кавычку не следует!).

Прописать директиву можно в двух местах – конфигурационном файле Apache httpd.conf или в файле управления доступом к директориям .htaccess. В первом случае вы должны иметь доступ к httpd.conf, а для этого вы должны являться администратором сервера (и, скорее всего, вам эта статья не понадобилась бы или пользователем хостинга - во втором случае. Причём на хостинге должно быть включено редактирование .htaccess самим пользователем (это позволяют все платные и почти все бесплатные службы хостинга). Кроме того, на платных серверах часто установлена панель управления сайтом cPanel. Так вот там можно самому создавать и редактировать страницы ошибок на основе SSI, даже если вы не специалист.

Короче, создаём в корне своего сайта файлик .htaccess и записываем в него строчку “ErrorDocument 400 400.html”, при условии, что файл 400.html уже существует.

Дальше начинается самое интересное, а именно – как будет выглядеть эта страничка. Создать страничку можно как минимум тремя способами.
Самый простой вариант – набросать в HTML-редакторе или “Блокноте” обычную страничку без графического оформления и сохранить её под нужным именем.
Вариант посложнее – можно добавить в этот HTML-файл директивы SSI, которые, к примеру, будут показывать URL, адрес, с которого пришёл пользователь, время, подключить внешние файлы и т.д.
Но согласитесь, первые два варианта – это примитив, не достойный настоящего веб-мастера. Опытные программисты пишут страницы ошибок на PHP. В этом есть одно достоинство – мы получаем доступ к переменным окружения, что даёт возможность лучше анализировать ошибочную ситуацию, выводить больше информации пользователю, вести лог ошибок в файле или базе данных, а не тупо выводить Not found и посылать бедного юзера на главную страницу.

Как вы уже догадались, мы будем рассматривать именно третий вариант. Начнём с простого – как PHP-скрипт получит код ошибки? Естественно, через параметр. Например, вот так:

error.php?400

В самом скрипте код ошибки после знака вопроса будет доступен в переменной $argv[0]. Теперь проверим скрипт (он должен вывести код ошибки, указанный после “?”):
<?php
echo $argv[0];
?>

Можно было бы передать параметр в классическом виде error.php?id=400, но так проще и безопаснее - этот скрипт принимает только одну переменную, зачем лишние лазейки? Сразу же обезопасим скрипт от ввода неверных данных: приведём код к целому типу и сделаем присвоение кода 404 по умолчанию, если скрипт был вызван без параметров. Приучайте себя к написанию безопасного кода! Теперь даже если ввести error.php?404abc или даже error.php?abc – значение переменной $id (она введена для читабельности) всё равно будет равно 404.
<?php

// проверяем переменную
$id = $argv[0];
$id = abs(intval($id));
if (!$id) $id = 404;
echo $id;

?>

Следующее, что мы сделаем – сопоставим коду русскоязычное описание. Это можно сделать при помощи операторов switch…case, но опытный программист сделает это более аккуратно и красиво – через ассоциативный массив, в котором ключ – это код ошибки, а значение – это её описание. Сделать такой массив очень просто, да и дополнять его легче, чем списки switch…case. Рекомендую начинающим программистам всегда использовать ассоциативный массив вместо switch…case, если в списке больше трёх позиций – выигрыш в скорости, размере кода и понятности. Список кодов ошибок можно найти на официальном сайте W3C (организация по веб-стандартам) http://www.w3.org/Protocols/HTTP/HTRESP.html или в любой книге по веб-программированию. Я сделал так:
<?php

// проверяем переменную
$id = $argv[0];
$id = abs(intval($id));
if (!$id) $id = 404;

// ассоциативный массив кодов и описаний
$a[401] = “Требуется авторизация”;
$a[403] = “Пользователь не прошел аутентификацию, доступ запрещен”;
$a[404] = “Документ не найден”;
$a[500] = “Внутренняя ошибка сервера”;
$a[400] = “Неправильный запрос”;

// выводим код и описание
echo “$id $a[$id]”;

?>

В результате выполнения этого кода пользователь увидит сообщение “404 Документ не найден” (по-крайней мере, так вывелось у меня, вы можете смоделировать другую ошибку). В принципе, тот же результат можно было получить при использовании первого способа, но разве я сказал, что мы на этом остановимся?

Кстати, пока не забыл. Ошибки с кодами 500…599 встречаются обычно, когда ошибку совершает сценарий, расположенный на вашем сервере. Некоторые интерпретаторы сценариев, например PHP, никогда не допускают такой ошибки. Если в вашем PHP-скрипте есть ошибка, интерпретатор сам выведет ошибочное сообщение с указанием её происхождения, а не просто “Ошибка”. Со стороны сервера это будет выглядеть как нормальный ответ клиенту, поэтому ошибка 500 при использовании PHP у вас практически никогда не возникнет. В отличие от него, Perl генерирует ошибку 500 и записывает сообщение о ней в лог сервера. Иди потом, разбери его – сложность отладки Perl-скриптов очень высокая. Это была одна из причин, по которой мне в своё время посоветовали перейти с Perl на PHP, что я и сделал, чего и вам желаю.

Вернёмся к написанию скрипта. Основная часть – обработка кода ошибки – уже готова, займёмся “довесками”. Для начала выведем поясняющее сообщение с ошибочным URL:
echo “Запрошенный Вами URL: <b>http://$SERVER_NAME$REQUEST_URI</b><br /> “;

Здесь включены две глобальные переменные $SERVER_NAME и $REQUEST_URI. Первая содержит имя сервера, вторая – URI (не путать с URL), который был запрошен. Выведем ещё на всякий случай IP-адрес, название браузера и текущее время на сервере.
$time = date(”d.m.Y H:i:s”);
Ваш IP: <b>$REMOTE_ADDR</b><br />
Ваш браузер: <b>$HTTP_USER_AGENT</b><br />
Текущее время сервера: <b>$time</b><br />

Согласитесь, это уже намного интересней. Если пользователь пришёл на ошибку по ссылке с другой страницы, покажем ему и этот URL этой страницы (переменная $HTTP_REFERER). Дополнительно можно показать реальный IP-адрес клиента, если он работает через прокси (переменная $HTTP_X_FORWARDER_FOR).
if ($HTTP_REFERER) $body .= “Вы пришли со страницы: <b>$HTTP_REFERER</b><br />\n”;
if ($HTTP_X_FORWARDER_FOR) $body .= “Ваш IP через прокси: <b>$HTTP_X_FORWARDER_FOR</b><br />\n”;

Ну и в завершение в самом низу “подпись” сервера (не на всех хостингах она работает корректно, потому что это чисто “серверная” переменная):
$_SERVER[’SERVER_SIGNATURE’]

Думаю, этой информации будет достаточно, для того чтобы пользователь не почувствовал, что пришёл на “последнюю страницу интернета”. Но есть ещё одна деталь, которую не упустит внимательный программист. Вспомните, откуда вы чаще всего попадаете на “ошибочные страницы”? Ну конечно из поисковых систем, в которых информация быстро устаревает. В подавляющем большинстве случаев мелкие проекты, типа FoxWeb переезжают с сервера на сервер, а потом на новом сервере сайт модернизируется, а старый остаётся на старом месте. Ну, в общем вы меня поняли :). У меня было так: первый сайт был открыт на kiiut.fatal.ru, потом всё его содержимое было скопировано на foxweb.net.ru. В поисковых системах хранятся ссылки на оба сайта. Через какое-то время старое содержимое на foxweb было удалено, а ссылки на него остались в поисковиках. Если заменить адрес сервера в ошибочной ссылке, то она вполне будет работать. Поясню на примере.

Предположим, человек нашёл в поисковой системе что-то вроде http://foxweb.net.ru/catalog/sbornik_fox1.html. У нашего сервера такой ссылки нет, но она должна была остаться на старом сервере со старым содержимым. Тогда предложим пользователю перейти по адресу http://kiiut.fatal.ru/catalog/sbornik_fox1.html. Опишем эту особенность в программе:
Возможно интересующую Вас информацию можно найти по старому адресу:<br />
<a href=”http://kiiut.fatal.ru$REQUEST_URI” mce_href=”http://kiiut.fatal.ru$REQUEST_URI” target=”_blank”><b>http://kiiut.fatal.ru$REQUEST_URI</b></a><br />

Даже если у вас не было такой ситуации, как у меня, возможно вы переписывали скрипты и адреса поменялись. Например, http://someserver.ru/catalog/ заменим на http://someserver.ru/?catalog или http://someserver.ru/cgi-bin/catalog.cgi. Надеюсь, общий смысл вам понятен, главное знать, что чем заменять.

Есть ещё одна особенность применения ошибочных страниц. Если несуществующая страница вызвана через вложенные директории, а заменяющая страница (наш скрипт) лежит в корне, то картинки на ней не будут отображены, а ссылки не будут работать. Почему? Это произойдёт в том случае, если вы используете на своём сайте относительные пути. Приведу пример:

http://someserver.ru/dir1/dir2/dir3/ - ошибочный адрес.
http://someserver.ru/error.php?404 – заменяющая страница будет вызвана по ОШИБОЧНОМУ ПУТИ, так как будто она там и хранится! Тогда ссылки на ней типа “page1.html” будут реально приводить вас по адресу http://someserver.ru/dir1/dir2/dir3/page1.html что будет вызывать ещё большее количество ошибок. Излечиться от этого можно, используя абсолютные пути ссылок и картинок (с именем сервера) или ставить перед относительным путём знак “/”, что на большинстве серверов указывает на корневую директорию сайта. Заметьте, что знак “./” будет указывать на текущую директорию.

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

Фрагмент файла http.conf или .htaccess для правильной обработки ошибок:

ErrorDocument 400 /error.php?400
ErrorDocument 401 /error.php?401
ErrorDocument 403 /error.php?403
ErrorDocument 404 /error.php?404
ErrorDocument 500 /error.php?500

Текст скрипта error.php:

<?php

$id = $argv[0];
$id = abs(intval($id));
if (!$id) $id = 404;

// ассоциативный массив кодов и описаний
$a[401] = “Требуется авторизация”;
$a[403] = “Пользователь не прошел аутентификацию, доступ запрещен”;
$a[404] = “Документ не найден”;
$a[500] = “Внутренняя ошибка сервера”;
$a[400] = “Неправильный запрос”;

// определяем дату и время в стандартном формате
$time = date(”d.m.Y H:i:s”);
// эта переменная содержит тело сообщения
$body =<<<END
Запрошенный Вами URL: <b>http://$SERVER_NAME$REQUEST_URI</b><br />
Возможно интересующую Вас информацию можно найти по старому адресу:<br />
<a href=”http://kiiut.fatal.ru$REQUEST_URI” mce_href=”http://kiiut.fatal.ru$REQUEST_URI” target=”_blank”><b>http://kiiut.fatal.ru$REQUEST_URI</b></a><br />
<br />
Ваш IP: <b>$REMOTE_ADDR</b><br />
Ваш браузер: <b>$HTTP_USER_AGENT</b><br />
Текущее время сервера: <b>$time</b><br />
END;
if ($HTTP_REFERER) $body .= “Вы пришли со страницы: <b>$HTTP_REFERER</b><br />\n”;
if ($HTTP_X_FORWARDER_FOR) $body .= “Ваш IP через прокси: <b>$HTTP_X_FORWARDER_FOR</b><br />\n”;
?>
<h1><i><?=$id?></i> <?=$a[$id]?></h1>
<p><?=$body?></p>
<?=$GLOBALS[’SERVER_SIGNATURE’]?>

Желаю всем удачного программирования и 200-го кода!

Автор: fox++
http://foxweb.net.ru/

Tags: 404, Apache, error, php

Добавить комментарий Март 21, 2008

Пишем PHP код, устойчивый к ошибкам

Предисловие

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

В этой статье я постараюсь собрать техники и приемы, позволяющие минимизировать количество ошибок в программе, написанной на PHP. Но некоторые из представленных методов могут пригодится если вы пишите на любом языке программирования.
Знание - половина успеха
Узнаем, о чем сообщает PHP

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

В PHP контроль вывода сообщений транслятора определяется функцией error_reporting и значением директивы error_reporting в php.ini. Рекомендуемое её значение E_ALL - т.е. выводить сообщения о всех потенциально опасных ситуациях. К ним в PHP относятся, например, использование неинициализированной переменной, обращение к несуществующему элементу массива и т.д.

Для включения максимально подробного вывода сообщений транслятора поставьте в начале программы вызов функции error_reporting:
// Для PHP4
error_reporting(E_ALL);

или поставьте значение error_reporting = E_ALL в php.ini.

С более подробном описании возможных уровней reporting можно знакомится в PHP документации - Error Handling and Logging Functions.

Для PHP5 введен уровень E_STRICT, который включает вывод сообщений о использовании в коде устаревших методов программирования (например, используется var для описания внутренних переменных класса). Он не входит в E_ALL, поэтому для PHP5 рекомендуемый уровень сообщений E_ALL | E_STRICT (т.е. E_ALL и E_STRICT). Соответственно, для задания вывода всех сообщений от транслятора надо вызвать error_reporting с таким параметром:
// Для PHP5
error_reporting(E_ALL | E_STRICT);
Если ни о чем не сообщает

Если Вы установили вывод ошибок и ошибки по не выводятся, то возможно вывод ошибок в script output отключен. Проверьте значение опции ini файла display_errors (она включает вывод ошибок непосрественно в script output) и, если она выключена, включите её.
// проверяет значение опции display_errors
if (ini_get(’display_errors’) != 1) {
// включает вывод ошибок вместе с результатом работы скрипта
ini_set(’display_errors’, 1);
}
Если вдруг сообщит

Крайне редко удается протестировать программу полностью до выпуска и в то-же время лучше не показывать пользователю сообщения об ошибках ибо его реакция на них непредсказуема. Лучше перенаправлять ошибки транслятора, которые произошли непосредственно во время работы программы, в log файл ошибок. Включить это перенаправление можно опцией log_errors в файле php.ini.

Полезно также поставить свой обработчик ошибок, если Вы хотите не только заносить ошибки в Log файл но и добавить некоторую дополнительную логику их обработки. Например, отправить письмо при сообщении транслятора или вывести некоторое специальное сообщение для пользователя. Подробнее об этом написано в статье Ловля ошибок в PHP, которую написал Антон Довгаль.
Сравниваем константу с переменной, а не наоборот

Сколько раз Вам приходилось выяснять, что ошибка в программе связанна с использованием оператора “=” вместо “==”? Что бы приходилось реже, используйте сравнения вида
if (10 == $i) {
// что-то делаем
}

В случае использования “=” вместо “==” транслятор выдаст ошибку “Parse error: parse error in … on line …”. Таким образом ошибка обнаруживается значительно быстрее.
Не используем значение дважды

Конечно, это преувеличение. Но если в программе возникает необходимость использовать значение несколько раз, можно порекомендовать объявить константу и использовать её вместо значения.

Для PHP4 существует единственный способ объявить константу - использовать функцию define.

Например:
define (’BEFORE_RENDER’, ‘beforeRender’);

Констант в классах объявлять нельзя.

Расширение PHP 5 для определения констант сходно с тем, которое было осуществлено при расширении от C до C++ - используется ключевое слово const. Но константы таким образом можно создавать только внутри классов.

Например:
class ControlEvents {
const BEFORE_RENDER = ‘beforeRender’;
}
print ControlEvents::BEFORE_RENDER;

Но для обращения к такой константе необходимо знать имя класса.

Константы могут быть также добавлены непосредственно в класс. Но PHP не поддерживает такой метод. Поэтому придется объявить их как обычные переменные:
class Control {

var $BEFORE_RENDER = ‘beforeRender’;
function render() {
$eventFunction = $this->BEFORE_RENDER;
$this->$eventFunction();
}
}
Проверка параметров функции

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

Для проверки типа используются следующие функции:
gettype(Mixed $var) - возвращает тип переменной.
Наиболее часто используемые типы: “boolean”, “integer”, “double”, “string”, “array”, “object”, “resource”, “NULL”.
Функции проверки на тип: is_bool(Mixed $var), is_integer(Mixed $var), is_double(Mixed $var), is_string(Mixed $var), is_array(Mixed $var), is_object(Mixed $var), is_resource(Mixed $var) - возвращают true или false.
Для определения класса объекта используются функции:
get_class(Object $obj) - возвращает имя класса, экземпляром которого является obj.
is_a(Object $obj, String $class) - проверяет, является ли obj экземпляром сласса class или класса, унаследованного от class.

Для PHP4 не существует автоматического способа проверки параметров функции. Все необходимые проверки необходимо делать самостоятельно.

Код функции, осуществляющей проверку аргументов, может быть примерно такой:
/**
* Функция showControl принимает один параметр $control,
* этот параметр должен являться классом и являться
* экземпляром класса HTMLControl либо классом,
* унаследованным от HTMLControl.
*/
function showControl(&$control) {
is_a($control, ‘HTMLControl’) or $control == null or exit(’Type missmatch.’);
…
}

Достоинство этого метода состоит в том, что можно управлять сообщениями об ошибках и использовать собственный обработчик ошибок. Например, Вы можете использовать следующие функции для проверки параметров:
function checkParameter(&$var, $class) {
if (!is_a($var, $class) && $var != null)
SFExit(’Type missmatch.’);
}

function SFExit(&$message) {
print $message . ‘<br>’;
$backtrace = debug_backtrace();
for($i = 0; $i < count($backtrace); $i++) {
print $i . ‘: ‘ . $backtrace[$i][’file’] . ‘(’ .
$backtrace[$i][’line’] . ‘)<br>’;
}
exit();
}

Примечание: Функция debug_backtrace введена только в PHP 4.3.0.

Пример их применения:
function showControl(&$control) {
checkParameter($control, ‘HTMLControl’);
…
}

Для PHP5 некоторые проверки типов параметров можно задать непосредственно в описании функции. Предыдущий пример на PHP5 будет выглядеть следующим образом:
function showControl(HTMLControl $control) {
…
}
Asserts

Во время создания и отладки программы можно использовать встроенный механизм добавления проверок в код программы. Он называется asserts (или assert-проверки). Идея его состоит в том, что в код программы добавляются специальные проверочные конструкции, которые можно отключить для production сайта, но в любой момент включить при разработке.

Следующие фрагменты кода примерно аналогичны:
/* Использование Asserts */
assert_options (ASSERT_ACTIVE, 1);

function showControl(&$control) {
assert(’is_a($var, \’HTMLControl\’) || $var == null’);
…
}
/* Использование if конструкций */
define(’ASSERT_ACTIVE’, 1);
function showControl(&$control) {
if (ASSERT_ACTIVE && !(is_a($var, ‘HTMLControl’) || $var == null’))
trigger_error(’Assertion failed’, E_USER_ERROR);
…
}

С помощью таких проверок также можно проверять параметры функций, возвращаемые функциями значения и т.д. Нужно лишь учесть, что assert-проверки не должны быть включены в реально действующем сайте - если программа нормально работает и проходит все проверки, то их можно отключить.
Проверять значения параметров скрипта $_REQUEST, $_GET, $_POST, $_COOKIES

PHP скрипт можно рассматривать как большую функцию, которая вызывается с неопределенным списком string параметров. Если предполагается, что некоторые параметры будут использоваться в некоторых вычислениях, или отправляться в базу данных, то их обязательно надо преобразовывать к требуемому типу и использовать только после явного приведения!

Все массивы REQUEST являются является обычными массивами, поэтому значения в них могут быть переопределены непосредственно.

Например:
if (isset($_GET[’id’]))
$_GET[’id’] = (int)$_GET[’id’];
else
$_GET[’id’] = null;
Разделяй и властвуй

Известный со времен древнего Рима принцип “Разделяй и властвуй” вполне может пригодится при разработке программ на любом языке программирования. В том числе и на PHP. Для реализации этого принципа разделяйте программу на логические блоки. Для этого можно воспользоваться следующими методами:

Использование функций.
Выносите структурные части алгоритма в функции. Проверяйте каждую часть отдельно и затем работу всего алгоритма в целом.

Использование классов.
Организуйте программный код в виде объектов, взаимодействующих друг с другом. Выделяйте сущности и оформляйте их в виде объектов. Внимательно рассматривайте, как они взаимодействуют друг с другом. Используйте, где это разумно, лучшие шаблоны проектирования (design patterns).

Разделяйте логику и HTML.
Для этого существует множество способов: темплейтные библиотеки, XML, XML/XSL. Подберите для себя наилучший и используйте.

Разделяйте логику самого приложения при помощи enterprise design patterns.
Используйте разделение приложения на уровни (layering) и другие технологии, позволяющие структурно разделить проект на крупные блоки.
Заключение

Возможно, кому-то материал статьи покажется сбором прописных истин. Но я думаю, что большинству он все-таки пригодится, а для начинающих программистов последний раздел “Разделяй и властвуй” может оказаться особенно полезным, поскольку задает направление изучения программирования.

Если у Вас есть комментарии или собственные приемы работы, которые не упомянуты в этой статье, я буду рад услышать и обсудить их с Вами.

Также хочу выразить признательность участникам клуба phpclub.ru за помощь в написании статьи.

Источник http://www.codenet.ru

Tags: error, php, PHP5, xml

Добавить комментарий Март 15, 2008