Архивная версия сайта e-luge.net. Последняя запись сделана 1 марта 2011 года.
Город съехавших крыш
27-03-2010 21:56   |  Метки: php, начинающим, формы, post, get, валидация

В наши дни сложно себе представить, что бы какой-нибудь современный сайт мог обойтись без форм. Гостевые книги, опросы, форумы, комментарии, обратная связь прочно вошли в жизнь простого серфера. Говорят, некоторых товарищей до сих пор приводит в священый трепет осознание того, что «написал текст, нажал кнопку, а через мгновение человек в другом конце мира может прочитать твоё сообщение». Да и разработчики не перестают радовать — добавление сообщений без перезагрузки страницы, загрузка файлов налету, уйма юзабилити экспериментов и т.д. и т.п. Можно только порадоваться.

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

Основные элементы формы

Перво-наперво, конечно же, сам тэг <form>, который, в паре с закрывающим </form>, определяет область действия нашей формы. Все интерактивные элементы, заключённые в контейнер <form> относятся к этому контейнеру.

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

Регистр. Имена служебных атрибутов и их значения регистронезависимы. Например, method = "get" и METHOD = "GET" воспримутся интерпретатором браузера одинаково. Однако, стоит внимательно следить за регистром значений атрибутов name и id, т.к. их используют как JavaScript, так и PHP.

Кавычки. Во многих источниках указано, что не имеет значение, ставить кавычки или нет, если только значение атрибутов не состоит из нескольких слов. Но, с приходом XHTML и XML они становятся обязательными. Точно так же, использование двойных кавычек в html в последствии может помочь избежать многих проблем.

Основные атрибуты тэга form

Method. По какому методу HTTP протокола должны быть переданы данные (GET или POST).

Оба метода передают данные, но чем же они отличаются? Во-первых, адрес страницы с переданным GET запросом будет выглядеть примерно так:

http://www.example.com/submit.php?element1=value1&element2=value2&element3=value3

Помните как выглядят ссылки на результаты поиска в гугле и яндексе?

http://www.google.com/search?rlz=1C1GGLS_ruBY340BY340&ie=UTF-8&q=php+and+forms
http://yandex.ru/yandsearch?clid=14585&text=php+and+forms&lr=157

Адрес страницы, с переданным POST запросом, выглядит иначе:

http://www.example.com/submit.php

Как видим, GET открыто передёт информацию. POST – прячет её от пользователя.

Во-вторых, размер GET запроса ограничен. Во многих источниках указыают 256 символов, включая адрес сайта, но в действительности, всё зависит от используемого браузера.

  • Microsoft Internet Explorer: длина GET-запроса лимитирована 2,048 символами.
  • Firefox: В версиях до 1.5 было ограничение в 64 килобайта. В более поздних версиях, говорят, ограничение снято.
  • Safari: Информации про лимит GET запроса не нашёл.
  • Opera: Разработчики утверждают, что лимита нет.

На POST браузеры никаких ограничений не накладывают.

Однако, давайте не будем забывать, что кроме того, что браузер отправляет данные, кто-то их должен принять. Этот кто-то — веб сервер, который точно так же накладывает свои ограничения.

  • Apache: по умолчанию 8Kib, но размер запроса и максимальное количество принимаемых параметров можно изменить с помощью директив LimitRequest*
  • ISS: по умолчанию 16Kib (может быть увеличено)

Так какой же метод и когда использовать?

Если мы хотим, чтобы страницу с результатами можно было вызвать по ссылке или добавить в закладки, то стоит использовать GET.

Если же нам надо передать конфиденциальные данные (например пароль) или какой-нибудь текст (заметки, комментарии), то, конечно, тут лучше подойдёт POST. Кроме того, если форма используется для отправки файла, то тоже следует использовать POST (но это уже совсем другая история).

Аction. Адрес скрипта, принимающего и обрабатывающего данные. Если action оставить пустым, либо вообще опустить, то данные будут отправлены на ту же самую страницу, где расположена форма. Если данные передаются методом POST, то все параметры, указанные в адресной строке сохранятся.

Например, форма находится по адресу http://www.example.com/form.php?id=10

  1. <!—данные будут отправлены на http://www.example.com/submit.php -->
  2. <form action="/submit.php">
  3. </form>
  4.  
  5. <!—данные будут отправлены на http://www.example.com/form.php?id=10 -->
  6. <form action="" method="POST">
  7. </form>
  8. <form method="POST">
  9. </form>

Но, если строго следовать спецификациям, а зачастую так и следует поступать, то action обязателен.

Enctype. MIME-тип для данных, отправляемых вместе с формой. Чаще всего опускается и используется значение по умолчанию application/x-www-form-urlencoded. Однако, в случае с загрузкой файлов, следует указывать multipart/form-data.

Name. Имя формы, позволяющее стилизовать элементы формы с помощью css или управлять формой с помощью скриптов.

Обращение к элементам по атрибуту name считается устаревшим и оставлено для обратной совместимости. Рекомендуется вместо name использовать атрибут id.

Target.

_blank
Загружает страницу в новое окно браузера.
_self
Загружает страницу в текущее окно.
_parent
Загружает страницу во фрейм-родитель, если фреймов нет, то этот параметр работает как _self.
_top
Отменяет все фреймы и загружает страницу в полном окне браузера, если фреймов нет, то этот параметр работает как _self.

С тэгом <form>, пожалуй, хватит. Оставшиеся атрибуты нас пока не интересуют.

Сама форма создаётся с помощью элементов input, select, textarea

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

Наиболее важными атрибутами элементов формы для нас являются name, позволяющее отделить один элемент от другого при обработке, и value – передаваемое значение элемента.

Имя элементов можно задать двумя способами: name = "fieldname" и name = "fields[]". Первый способ предпочтительно использовать для уникальных полей, кнопок и переключателей, текстовых полей и выпадающих списков с возможностью выбора только одного значения. Второй – для элементов, которые позволяют множественный выбор (чекбоксы, выпадающие списки с параметром multiple).

Принимаем данные

После того, как пользователь заполнил форму и нажал «Отправить», данные, как мы уже знаем, отправляются в скрипт-обработчик, указанный в атрибуте action.

В зависимости от использованного метода передачи данных мы можем использовать суперглобальные массивы $_GET, $_POST и $_REQUEST. Массивы $_GET и $_POST содержат в себе данные, переданные с помощью GET и POST методов соответственнно. Массив $_REQUEST не столь однозначен. Ассоциативный массив $_REQUEST содержит в себе объединённые данные из суперглобальных массивов $_GET, $_POST и $_COOKIE (доступные на странице куки).

В самом упрощённом виде мы можем принять данные так:

  1. <?php
  2. // метод GET
  3. $page = $_GET['page'];
  4.  
  5. // метод POST
  6. $text = $_POST['text'];
  7.  
  8. // пример с $_REQUEST. Получаем и GET и POST данные из одного массива
  9. $page = $_REQUEST['page'];
  10. $text = $_REQUEST['text'];
  11. ?>

Как видим, всё достаточно просто и прозрачно.

В случае использования массива $_REQUEST следует помнить об одной его особенности — данные, поступающие в него, собираются из массивов $_GET, $_POST и $_COOKIE, причём, если разными методами переданы параметры с одинаковыми именами, то в $_REQUEST будет содержаться только один параметр с этим именем. За порядок заполнения отвечает директива variables_order в php.ini, по умолчанию сначала добавляются данные из $_GET, потом $_POST и завершает всё $_COOKIE.
Пример:

  1. <?php
  2. echo '<pre>'.
  3. print_r($_GET,true). // выведет [text] => 1
  4. print_r($_POST,true). // выведет [text] => 2
  5. print_r($_REQUEST,true). // выведет [text] => 2
  6. '</pre>';
  7. ?>
  8. <form method="POST" action="script.php?text=1">
  9. <input name="text" value="2" />
  10. <input type="submit" name="go" value="Check" />
  11. </form>

Использованная здесь функция print_r() позволяет вывести в браузер значение переменной (в данном случае содержимое массива), что часто используется в отладке скриптов.

Дальнейший материал проще разбирать на примере, поэтому давайте создадим простую форму регистрации:
  1. <form action="myform1.php" method="post">
  2. <fieldset>
  3. <legend>Регистрация</legend>
  4. <div>
  5. <label for="name">Имя:</label>
  6. <input type="text" name="f_name" value="" id="name"/>
  7. </div>
  8. <div>
  9. <label for="password">Пароль:</label>
  10. <input type="password" name="f_password" value="" id="password"/>
  11. </div>
  12. <div>
  13. <label for="mail">E-mail:</label>
  14. <input type="text" name="f_mail" value="" id="mail"/>
  15. </div>
  16. <div>
  17. <label for="country">Страна:</label>
  18. <select name="f_country" id="country">
  19. <option value="BWA">Ботсвана</option>
  20. <option value="MAR">Марокко</option>
  21. <option value="TZA">Танзания</option>
  22. </select>
  23. </div>
  24. <div>
  25. Я <label class="small"><input type="radio" name="f_gender" value="male" /> Мужчина</label>
  26. <label class="small"><input type="radio" name="f_gender" value="female" /> Женщина</label>
  27. </div>
  28. <div>
  29. <label for="like">Мне нравится</label>
  30. <select name="f_like[]" id="like" multiple="multiple">
  31. <option value="read">Читать</option>
  32. <option value="walk">Гулять</option>
  33. <option value="smoke">Курить</option>
  34. <option value="drink">Пить</option>
  35. <option value="teach">Учить</option>
  36. </select>
  37. </div>
  38. <div>
  39. <label for="subscribe" class="full">Подписаться на рассылку
  40. <input type="checkbox" name="f_subscribe" checked="checked" id="subscribe"/></label>
  41. </div>
  42. <div>
  43. <input type="submit" name="send" value="Отправить" />
  44. </div>
  45. </fieldset>
  46. </form>

Основные проверки

Любую разработку или отладку стоит проводить с выводом ВСЕХ ошибок и замечаний. То, что вам кажется незначительным, впоследствии может серьёзно повлиять на работу скрипта. Так что не забываем указывать в самом начале ini_set('display_errors',1); и error_reporting(E_ALL);

Для начала, необходимо определить, что в скрипт пришли данные. Тут, как и практически в любой задаче есть несколько способов решения.

1. Проверить, что из формы пришёл некий параметр. Обычно это имя кнопки-сабмита

  1. <?php
  2. if (isset($_POST['send'])) {
  3. // к нам что-то пришло
  4. }
  5. ?>

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

2. Проверить, что суперглобальный массив содержит в себе данные

  1. <?php
  2. if (!empty($_POST)) {
  3. // к нам что-то пришло
  4. }
  5. ?>

или

  1. <?php
  2. if (count($_POST)) {
  3. // к нам что-то пришло
  4. }
  5. ?>

3. Проверить метод, каким был послан запрос

  1. <?php
  2. if ($_SERVER['REQUEST_METHOD'] == 'POST') {
  3. // к нам что-то пришло
  4. }
  5. ?>

По-моему, наиболее подходящий вариант — мы проверяем именно способ запроса, не привязываясь к конкретным данным.


«Notice: Undefined index» — знакомое замечание? Стоит обратиться к несуществующему индексу массива и вот оно, тут как тут.

В FAQ’e одного известного российского интернет магазина (http://www.phpshop.ru/gbook/ID_745.html) пишут:
"Re: Notice: Undefined index Notice: Undefined offset Notice: Undefined variable"
У вас выводится отладочная информация для разработчиков, которая не должна выводится для пользователей в магазине - это серьезная ошибка вашего хостинга. Для ее закрытия лучше всего отключить вывод ошибок в php.ini или в файле .htaccess вставить строку php_flag error_reporting 0

Так вот, никакая это не ошибка хостинга. Это просто лень и головотяпство разработчиков. Входящие данные надо проверять. Всегда. А отключение вывода ошибок — лечение симптомов, но не самой болезни.

Что же сделать, чтобы не уподобляться таким горе-программистам?

  1. <?php
  2. if (($_SERVER['REQUEST_METHOD']) == 'POST') {
  3. // к нам что-то пришло
  4.  
  5. if (isset($_POST['var']) && !empty($_POST['var'])) {
  6. // пришёл параметр var
  7. $var = $_POST['var'];
  8. } else {
  9. die('Заполните все поля');
  10. }
  11. }
  12. ?>

Для начала, с помощью isset() надо убедиться, что нужная переменная содержится в массиве $_POST, а потом, проверить, что переменная не пустая (empty())

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

Итак, сейчас мы можем написать небольшую проверку для нашей формы.

  1. <?php
  2. if (($_SERVER['REQUEST_METHOD']) == 'POST') {
  3. // к нам что-то пришло
  4.  
  5. if (isset($_POST['f_name']) && !empty($_POST['f_name'])) {
  6. // пришёл параметр f_name
  7. $name = $_POST['f_name'];
  8. } else {
  9. die('Заполните поле «Имя»');
  10. }
  11.  
  12. if (isset($_POST['f_password']) && !empty($_POST['f_password'])) {
  13. // пришёл параметр f_password
  14. $password = $_POST['f_password'];
  15. } else {
  16. die('Заполните поле «Пароль»');
  17. }
  18.  
  19. if (isset($_POST['f_mail']) && !empty($_POST['f_mail'])) {
  20. // пришёл параметр f_mail
  21. $mail = $_POST['f_mail'];
  22. } else {
  23. die('Заполните поле «E-mail»');
  24. }
  25.  
  26. if (isset($_POST['f_country']) && !empty($_POST['f_country'])) {
  27. // пришёл параметр f_country
  28. $country = $_POST['f_country'];
  29. } else {
  30. die('Заполните поле «Страна»');
  31. }
  32.  
  33. if (isset($_POST['f_gender']) && !empty($_POST['f_gender'])) {
  34. // пришёл параметр f_gender
  35. $gender = $_POST['f_gender'];
  36. } else {
  37. die('Заполните поле «Пол»');
  38. }
  39.  
  40. if (isset($_POST['f_like']) && !empty($_POST['f_like'])) {
  41. // пришёл параметр f_like
  42. $like = $_POST['f_like'];
  43. } else {
  44. die('Заполните поле «Хобби»');
  45. }
  46.  
  47. if (isset($_POST['f_subscribe']) && !empty($_POST['f_subscribe'])) {
  48. // пришёл параметр subscribe
  49. $subscribe= true;
  50. } else {
  51. $subscribe= false;
  52. }
  53. // … сохраняем пользовательские данные …
  54. }
  55. ?>

Обратите внимание, проверка для параметра f_subscribe отличается от всех остальных. Так как «подписка» — параметр не обязательный, то в случае его отсутствия мы не останавливаем скрипт.

Несколько монструозно, верно? Да и ошибки, выводимые с помощью die(), никак не соотносятся с понятием «удобная форма». В случае, когда для валидации формы достаточно просто заполненности полей, можно сделать форму немного универсальней:

  1. <?php
  2.  
  3. /**
  4.  * проверить, что данные переданы методом POST
  5.  *
  6.  * @return bool
  7.  */
  8. function is_post()
  9. {
  10. if ($_SERVER['REQUEST_METHOD'] == 'POST') {
  11. return true;
  12. } else {
  13. return false;
  14. }
  15. }
  16.  
  17. /**
  18.  * проверить, что $_POST содержит соответствующий элемент
  19.  *
  20.  * @param string $var_name
  21.  * @return bool
  22.  */
  23. function checkPostVar($var_name)
  24. {
  25. if (isset($_POST[$var_name]) && !empty($_POST[$var_name])) {
  26. return true;
  27. } else {
  28. return false;
  29. }
  30. }
  31.  
  32. // массив возможных ошибок, если поле не заполнено
  33. $error_text = array(
  34. 'f_name' => 'Заполните поле «Имя»',
  35. 'f_password' => 'Заполните поле «Пароль»',
  36. 'f_mail' => 'Заполните поле «E-mail»',
  37. 'f_country' => 'Заполните поле «Страна»',
  38. 'f_gender' => 'Заполните поле «Пол»',
  39. 'f_like' => 'Заполните поле «Интересы»'
  40. );
  41.  
  42. //
  43. $values = array(
  44. 'f_name' => '',
  45. 'f_password' => '',
  46. 'f_mail' => '',
  47. 'f_country' => '',
  48. 'f_gender' => '',
  49. 'f_like' => ''
  50. );
  51.  
  52. $errors = array();
  53.  
  54. if (is_post()) {
  55.  
  56. // поверяем, что поля заполнены
  57. foreach ($values as $k => $v) {
  58. if (checkPostVar($k)) {
  59. $values[$k] = $_POST[$k];
  60. } else {
  61. // если поле не заполнено, то сохраняем ошибку
  62. $errors[] = $k;
  63. }
  64. }
  65.  
  66. if (checkPostVar('f_subscribe')) {
  67. $values['f_subscribe'] = true;
  68. } else {
  69. $values['f_subscribe'] = false;
  70. }
  71.  
  72. if (empty($errors)) {
  73. // … сохраняем пользовательские данные из $values…
  74. } else {
  75. // выводим ошибки
  76. foreach ($errors as $v) {
  77. echo $error_text[$v].'<br />';
  78. }
  79. }
  80. }
  81. ?>

Внешнее усложнение кода лишь кажущееся. На самом деле скрипт стал универсальнее, проще для добавления или изменения полей, да и тексты ошибок теперь собраны в одном месте.

Специфические проверки

Если бы валидация пользовательских данных заключалась только в проверке того, что поля заполнены, то на этом можно было бы и закончить. Но, ведь, часто необходимо, чтобы данные соответствовали неким специфическим требованиям (например, длина пароля или e-mail). В этом случае универсальной проверкой уже не обойтись.

Добавим ещё один массив, содержащий текст ошибок для наших уникальных полей

  1. <?php
  2. $additional_errors = array(
  3. 'f_password' => 'Минимальная длина пароля — 6 символов',
  4. 'f_mail' => 'Введите e-mail адрес',
  5. );
  6. ?>

и дополнительные проверки пароля и e-mail'a

  1. <?php
  2. // проверяем длину пароля
  3. if (!array_key_exists('f_password', $errors) &&
  4. strlen($values['f_password']) < 6) {
  5. $errors['f_password'] = $additional_errors['f_password'];
  6. }
  7.  
  8. // проверяем e-mail на соответствие шаблону
  9. $pattern = '~^[_a-z0-9-]+(\.[_a-z0-9-]+)*@[a-z0-9-]+(\.[a-z0-9-]+)*(\.[a-z]{2,4})$~i';
  10. if (!array_key_exists('f_mail', $errors) &&
  11. !preg_match($pattern, $values['f_mail'])) {
  12. $errors['f_mail'] = $additional_errors['f_mail'];
  13. }
  14. ?>

Для того, чтобы не проводить проверку данных из незаполненного поля, мы добавили условие array_key_exists('индекс', $errors).

Сохранение пользовательского ввода

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

Добавим ещё одну функцию, переводящую данные к html-сущностям не только в строке, но и в массиве. А так же подправим вывод ошибок.

  1. <?php
  2. /**
  3.  * прогнать данные через htmlspecialchars
  4.  *
  5.  * @param mixed $var
  6.  * @return mixed
  7.  */
  8. function htmlsc($var)
  9. {
  10. if (is_array($var)) {
  11. $res = array();
  12. foreach ($var as $k => $v) {
  13. $res[$k] = htmlsc($v);
  14. }
  15. }
  16. else {
  17. $res = htmlspecialchars($var, ENT_QUOTES);
  18. }
  19.  
  20. return $res;
  21. }
  22. ?>
  1. <?php
  2. if (empty($errors)) {
  3. // … сохраняем пользовательские данные из $values…
  4. } else {
  5. // выводим ошибки
  6. echo implode('<br />', $errors);
  7. foreach ($values as $k => $v) {
  8. $values[$k] = htmlsc($v);
  9. }
  10. }
  11. ?>

и в самой форме добавим в поля значения из $values

для текстовых полей

  1. <input type="text" name="f_name" value="<?php echo $values['f_name']?>" />

для выпадающего списка

  1. <select name="f_country">
  2. <option value="BWA" <?php echo ('BWA' == $values['f_country'])?'selected="selected"':''?>>Ботсвана</option>
  3. <option value="MAR" <?php echo ('MAR' == $values['f_country'])?'selected="selected"':''?>>Марокко</option>
  4. <option value="TZA" <?php echo ('TZA' == $values['f_country'])?'selected="selected"':''?>>Танзания</option>
  5. </select>
  6.  

для переключателей

  1. <input type="radio" name="f_gender" value="male" <?php echo ('male' == $values['f_gender'])?'checked="checked"':''?>/>

и для флажков

  1. <input type="checkbox" name="f_subscribe" <?php echo ($values['f_subscribe'])?'checked="checked"':''?>/>

Пример формы и окончательный исходник

Заключение

На последок, хотелось бы ещё раз отметить: всегда проверяйте данные, приходящие от пользователя. Я не призываю к параноидальному «хакеры везде», но беспечно оставлять всё на самотёк также не стоит. То же самое можно сказать и о проверке формы с помощью JavaScript’a. JavaScript — способ быстрее, без перезагрузки страницы, сообщить пользователю об ошибках, но это всего лишь дополнительная проверка. Основная проверка всегда должна проходить на сервере.

Комментарии (6):
Костег (на php.ru/forum тоже есть) 31-03-2010 19:15
Имхо слишком просто) Я-то думал, что статья будет не только о валидации, но и о генерации их.

Вот, кста, я разрабатываю кой-че
http://code.google.com/p/bicycle-libraries/source/browse/#hg/src/core
там есть Validator. Но пока не очень тестирован
Костег (на php.ru/forum тоже есть) 31-03-2010 19:17
+я не уверен, но имхо

if (isset($_POST[$var_name]) && !empty($_POST[$var_name])) {
// безболезненно заменяется на
if (!empty($_POST[$var_name])) {
// без нотайсов, если ключ не существует
Luge 31-03-2010 20:06
Костег, статья писалась с целью собрать и несколько систематизировать информацию для новичков, ищущих её по сети. Я вовсе не сомневаюсь, что приведённое здесь для многих естественно как воздух, но, я, ведь, и не обещал открыть путь в терру инкогнито :)

Мне не совсем нравится идея isset() vs empty(). Это разные функции, проверяют они разные вещи. Да, и просто мне нравится, что сначала мы проверяем то, что переменная существует, а потом уже содержимое этой переменной. Может, несколько излишне, но, ведь, в магазине мы перед тем, как рассчитаться с продавцом, сначала достаём кошелёк и только потом проверяем наличие необходимой суммы. Так почему в php действовать иначе? К тому же, просто проверка на пустоту так же не всегда уместна.

Костег (на php.ru/forum тоже есть) 31-03-2010 20:22
да, именно поэтому я в своем валидаторе для правила 'notEmpty' добавил параметр "значения, которые не считаются пустыми".

empty('0') // true
// а в валидаторе '0' - не пустое значение
$validator->addRule('fieldName', 'notEmpty', 'Поле %field% пустое', array('allowed' => array('0')))


Хочу статей для "не новичков" =). Про те же генераторы форм. Вот я до сих пор не пойму: хорошо это или плохо генерировать форму через пых, а не прописывать ее в шаблоне. Пока пользуюсь 2-ым вариантом.
Luge 31-03-2010 20:36
Для фрэймворка или, даже, приложения, позволяющего простым пользователям создавать свои формы/анкеты — однозначно полезно. Но, естественно, тут вопрос не в том, нужны - не нужны, а в стоит в данном случае применять или нет. Ещё один момент — важно, чтобы api генератора не стал сложнее, чем ручное написание форм, а то игра не стоит свеч.
Беляш 13-04-2010 10:34
Хорошая статья. Проверка с !isset() кажеться более логичной, чем просто !empty($_POST[$var_name]). Я за
if (isset($_POST[$var_name]) && !empty($_POST[$var_name]))

Хороший блог -> в закладки.

Спасибо.

Это архив блога. Добавление комментариев запрещено.

© Павел Новицкий 2009 - 2011
(: time: 28.4s, sql: 65, memory: 246Mb :)