Такой возглас можно простить разве что не по годам уставшей от жизни девушке в окошке паспортного стола, но никак не веб-приложению, обрабатывающему регистрационную анкету или иную подобную форму. Человеку свойственно ошибаться. Он может по рассеяности не заполнить несколько обязательных полей, несмотря на предупреждающие "звездочки" напротив комментариев к ним, или же из самых лучших побуждений вставить недопустимый пробельный символ в свой почтовый адрес. Содной стороны, грамотный скрипт не должен принмать к обработке "недоделанную" анкету. С другой - приложение ни в коем случае не имеет права потребовать от пользователя заполнения всей анкеты заново, иначе он плюнет и уйдет на другой, более дружелюбный сервер. Любая веб-форма, состоящая более чем из трех полей и предполагающая предварительную проверку их значений на стороне сервера, должна предусматривать возможность запоминания уже введенных значений в случае возможного повторного заполнения полей при "откате".
Перед самым началом проектирования какого-либо серьезного скрипта полезно в общих чертах наметить логику его работы. Предлагаю ознакомиться с типовым вариантом алгоритма функционирования приложения, включающего в себя одну веб-форму:
- Вывести все необходимые заголовки и "шапку" страницы
- Прочесть пользовательский запрос. В случае заполненного запроса вычленить имена и значения параметров, декодировать их.
- Проанализировать параметры. Если параметры не заданы или же заданы неполно или неправильно, перейти к пятому шагу.
- Выполнить основной функциональный блок приложения - обработку пользовательских данных и сопряженные действия (отправку анкеты, поиск в базе данных на основании пользовательского запроса и т.д.). Вывести отчет. Перейти к последнему шагу.
- Вывести HTML-форму, подставляя в ее поля соответствующие значения принятых пользовательских параметров.
- Вывести "подвал" страницы и завершить выполнение скрипта.
Не правда ли, весьма наглядная и простая схема? Добавляя к этому шаблону новые пункты, можно проектировать логику работы приложений со сколь угодно сложными ветвлениями и совершенно произвольным количеством форм. Каждый шаг алгоритма удобно оформить в виде отдельной подпрограммы (или даже нескольких подпрограмм с комментариями на будущее).
Остановимся, однако, на пятом пункте. Вот возможный пример описания одного из полей формы в коде скрипта:
print"<p>Адрес электронной
почты*:<input name=\"email\"
size=\"25\"maxlength=\"50\"
value=\"$userdata{'email'}\"></p>\n";
Конструкция, прямо скажем, не намного сложнее "голого" HTML. Обратите внимание на значение атрибута value тэга : туда подставляется значение параметра, отправленного пользователем на предыдущем шаге. (Будем полагать, что значения всех принятых пользовательских параметров при разборе строки запроса были помещены в хэш %userdata, ключами которого являются имена параметров.) Если же посетитель сайта на предыдущем шаге работы со скриптом забыл заполнить соответствующее поле, в его описании в HTML-коде веб-формы будет фигурировать value='''', то есть поле попросту останется пустым. То же самое относится к случаю, когда скрипт запущен впервые и никаких данных ему еще не было передано.
С текстовыми полями и впрямь все просто. А как быть с радиокнопками, списками и прочими подобными элементами? Здесь, к сожалению, все не так прозрачно.
Для того, чтобы наделить "памятью" простейший список с двумя опциями - "yes" и "no", придется, по всей видимости, воспользоваться такой конструкцией:
Списки в сотни позиций, скажем прямо, управляемы с трудом. Можно, конечно, присвоить каждому пункту списка числовой код при помощи атрибула value, ввести ряд вспомогательных переменных, как-нибудь обыграть все это - тогда, возможно, удастся сделать блок условий чуть более элегантным.