Как работать с формами

Работа с формами

Внешний вид приложения является нам преимущественно через формы. Формы являются основными строительными блоками. Они предоставляют контейнер для различных элементов управления. А механизм событий позволяет элементам формы отзываться на ввод пользователя, и, таким образом, взаимодействовать с пользователем.

При открытии проекта в Visual Studio в графическом редакторе мы можем увидеть визуальную часть формы — ту часть, которую мы видим после запуска приложения и куда мы переносим элементы с панели управления. Но на самом деле форма скрывает мощный функционал, состоящий из методов, свойств, событий и прочее. Рассмотрим основные свойства форм.

Если мы запустим приложение, то нам отобразится одна пустая форма. Однако даже такой простой проект с пустой формой имеет несколько компонентов:

Несмотря на то, что мы видим только форму, но стартовой точкой входа в графическое приложение является класс Program, расположенный в файле Program.cs:

Сначала программой запускается данный класс, затем с помощью выражения Application.Run(new Form1()) он запускает форму Form1. Если вдруг мы захотим изменить стартовую форму в приложении на какую-нибудь другую, то нам надо изменить в этом выражении Form1 на соответствующий класс формы.

Сама форма сложна по содержанию. Она делится на ряд компонентов. Так, в структуре проекта есть файл Form1.Designer.cs, который выглядит примерно так:

Здесь объявляется частичный класс формы Form1, которая имеет два метода: Dispose() , который выполняет роль деструктора объекта, и InitializeComponent() , который устанавливает начальные значения свойств формы.

При добавлении элементов управления, например, кнопок, их описание также добавляется в этот файл.

Но на практике мы редко будем сталкиваться с этим классом, так как они выполняет в основном дизайнерские функции — установка свойств объектов, установка переменных.

Еще один файл — Form1.resx — хранит ресурсы формы. Как правило, ресурсы используются для создания однообразных форм сразу для нескольких языковых культур.

И более важный файл — Form1.cs, который в структуре проекта называется просто Form1, содержит код или программную логику формы:

Руководство по HTML-формам

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

Необходимые условия

Перед началом этого модуля вам следует изучить хотя бы Введение в HTML. На данный момент у вас не должно возникнуть сложностей с пониманием Основных руководств и использованием нашего руководства по Стандартным виджетам форм.

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

**Примечание:**Если компьютер/планшет/другое устройство, на котором вы работаете, не позволяет вам самостоятельно создавать файлы, то приводимые здесь примеры кода можно посмотреть в онлайновых программах для кодирования, например JSBin или Thimble.

Основные руководства

Первая статья в серии даёт вам начальный опыт в создании HTML-форм, включая разработку простой формы, её реализация при помощи элементов HTML, стилизация при помощи CSS и то, как данные отправляются на сервер.

Изучив основы, рассмотрим более подробно элементы, используемые для структурирования и придания смысла различным частям HTML-форм.

Какие виджеты форм доступны?

Рассмотрим подробнее функционал различных виджетов форм; какие варианты доступны для сбора различных типов данных.

Валидация и подтверждение данных форм

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

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

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

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

В этой статье рассматриваются способы использования формы для сборки HTTP-запроса и отправки его через пользовательский JavaScript вместо стандартного представления формы. А также почему вы захотите это сделать и способы реализации (см. использование объектов FormData).

Статья раскрывает особенности обнаружения и т.д. (см. Кросс-браузерное тестирование для более глубокого понимания)

Руководства по стилизации форм

Вступительная статья по стилизации форм с помощью CSS, включая все необходимые основы.

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

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

HTML-формы. Взгляд бэкенд-разработчика

При подготовке материала по Symfony Form я решил уделить некоторое внимание теоретической части по работе с формами со стороны клиента – что они из себя представляют, как ведут себя браузеры при отправке, в каком формате путешествуют, в каком виде поступают на сервер.

Вводная часть несколько растянулась и в итоге вылилась в отдельную небольшую статью, которая, по моему мнению, может быть интересна и другим бэкенд-разработчикам (не только PHP или Symfony).

В тексте будут использоваться два похожих термина: поле формы и элемент формы. Оба в большинстве случаев взаимозаменяемы и обозначают некоторую часть формы. Но для удобства и порядка полями чаще будут называться части, которые содержат непосредственно значения и, вероятно, будут отправлены на сервер, а элементами – декоративные части формы.

Раньше работа с формами была в каком-то смысле проще: в том виде, в котором форма приходила к пользователю, в том же она отправлялась и обратно, но уже с заполненными полями. Бэкенд-разработчики точно знали какой набор данных им следует ожидать, всё было легко и предсказуемо. С широким распространением JS всё изменилось: сегодня уже никого не удивляет поведение приложения, при котором форма приходит с одним набором полей, а отправляется с совершенно иным, когда громоздкие формы имеют в своём составе небольшие динамические подформы, которые независимо от основной могут отправляться на сервер для обработки, когда выбранные файлы загружаются в фоновом режиме, в то время как пользователь заполняет остальную часть формы. Таким образом, всё большее количество логики переносится на сторону клиента, и это отлично, в первую очередь, конечно же, для пользователя. Для разработчика процесс работы с формами несколько усложнился. Но как бы тяжело ему не было, игнорировать развитие технологий сегодня невозможно, поэтому необходимо уметь эффективно их использовать.

Бэкенд против Фронтенда

Мы постоянно стремимся к автоматизации всего, с чем нам приходится работать, особенно рутинных задач, при этом пытаемся привнести в эти процессы некий порядок. Поэтому многих разработчиков несколько пугает динамичность на клиентский стороне, которая часто воспринимается ими как неконтролируемый хаос. Можно подумать, что у фронтенд-разработчиков развязаны руки, и они могут творить подобно художникам и скульпторам, их действия ничем не ограничены, а нам потом разбирать на сервере полёты их фантазии. Нередко так и случается, но это ошибочный, тупиковый путь. Это можно сравнить со schemaless-хранилищами данных: никто вас не ограничивает жёсткой структурой хранения данных, каждый из разработчиков в рамках одного проекта может придумать свой формат хранения, потом поменять его в зависимости от настроения, что в конечном счёте, скорее всего, приведёт к печальным последствиям. Если же вы ожидаете от своего продукта гибкости, легкой расширяемости и динамичного развития, вам необходимо будет придерживаться определённых правил, которые помогут поддерживать порядок в вашем приложении. То же самое вы в праве требовать и от фронтенд-разработчиков – творите, но придерживайтесь правил.

Итак, что вам, как бэкенд-разработчику, необходимо понять и принять:

Перестаньте бояться динамики на серверной стороне.
Мир и технологии не стоят на месте, и если вы не будете успевать под них подстраиваться, вы проиграете. Сегодня неотъемлемая часть нашей жизни, и вам придётся с этим смириться, хотите вы этого или нет. Теперь при работе с формами необходимо ориентироваться не только и не столько на заранее определенную разработчиком жёсткую структуру полей, сколько на пришедшие от пользователей данные.

Отправляем форму

Отлично, мы каким-то образом сгенерировали HTML для некоторой формы и отправили её пользователю. Заполнив поля и, возможно, изменив структуру формы, пользователю необходимо отправить её на сервер для обработки. Каким образом он может это сделать? Есть разные способы, большинство из которых потребует выполнения скриптов. Рассмотрим основные:

1. Нажатие на кнопку отправки формы.
2. Вызов метода submit() у объекта формы.
3. Сериализация полей формы.
4. Создание и формирование произвольного запроса.

Пусть работает браузер

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

1. Определяет форму, поля которой необходимо отправить.
2. Определяет набор полей, которые подлежат отправке. В этот набор входят следующие элементы формы: button, input, keygen, object, select, textarea.
3. Генерирует пары ключ=значение, где ключом является имя поля (атрибут name), а значением – содержимое данного поля.
4. Создает и формирует запрос, который будет выполнен методом, указанным в атрибуте тега формы method и тело которого будет закодировано в зависимости от значения атрибута enctype.
5. Отправляет запрос на сервер по адресу, указанному в атрибуте тега формы action.

Атрибуты formmethod, formenctype и formaction нажимаемой кнопки переопределяют соответственно значения атрибутов method, enctype и action родительской формы.

Это очень простой процесс, но важно в нём разобраться, чтобы однозначно понимать, какие данные и в каком виде мы получаем на сервере.

Из всего списка наиболее интересен третий пункт – генерация пар ключ=значение. Каждый элемент формы должен иметь атрибут name, который будет использован браузером в качестве ключа. Рассмотрим на примере. Имеется следующая форма:

В этом случае браузер сформирует две пары ключ=значение: nickname=ghost и password=123456. При отправке они будут склеены с помощью символа амперсанда (&), и в результате на сервер будет отправлен запрос, тело которого содержит строку:

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

На что в этом процессе следует обратить внимание:

Вся поступающая к вам информация будет представлена в виде текстовых значений.
Какой бы сложной ни была клиентская часть работы с формой, вы в любом случае получите всю информацию в текстовом (строковом) виде. Если это работа с картографическими сервисами, результатом будут координаты. Если это WYSIWYG-редактор, то в зависимости от типа редактора результатом будет либо HTML-код, либо текст в markdown-разметке, либо текст в любом другом заранее известном вам формате. Это важный пункт, осознание которого поможет побороть страх перед громоздкими сложными формами. Разумеется, это не относится к загружаемым файлам.

• radio
• checkbox
• select с атрибутом multiple

Также в запрос не будут включены значения кнопок, как обычных, так и submit, которые не участвуют в отправке формы, т.е. те кнопки, по которым не было совершено нажатие. Таким образом, если отправка выполняется методом submit(), в запрос не будет включена ни одна кнопка.

Не будут отправлены также поля, находящиеся в отключённом состоянии (имеющие атрибут disabled).

Многие предполагают, что браузер каким-то образом должен решить, какое одно из двух полей необходимо отправлять в запросе. Логика подсказывает, что отправлять необходимо последнее (в данном случае второе), которое перекрывает все предшествующие поля с тем же именем. Это предположение неверно!
Браузер вообще не волнует, есть в форме какие-то конфликты имён или их нет. Непустое имя поля не является критерием исключения данного поля из отправляемого запроса. Другими словами, для браузера оба поля являются корректными и оба будут включены в набор отправляемых полей, причем в том порядке, в котором они представлены в форме.
Таким образом, приведённая выше форма при отправке на сервер примет следующий вид:

Именно такой запрос и придёт на наш сервер. Вы можете проверить это, прочитав значение php://input. Что же с этим запросом будет делать PHP? Всё как обычно – разбирает строку и формирует массив $_POST. Но, как мы знаем, ключи в массивах уникальны, поэтому первоначальное значение «John Doe» будет перезаписано значением «Mike Ross». В итоге мы получим следующий результат:

Теперь должно стать понятно, как работает хак со скрытым полем для checkbox. Посмотрим на следующую форму:

Видим два поля с одинаковыми именами. Если checkbox будет выбран, в запрос будут добавлены оба поля в том порядке, в котором они представлены в форме, а значит значение «0» поля hidden будет перезаписано значением «1» поля checkbox. Если же checkbox выбран не будет, то согласно пункту 2 его значение не отправляется, а значит в запросе будет только поле hidden со значением «0», которое и будет получено на сервере и помещено в массив $_POST.

manager_fullname и developer_fullname – самый простой и очевидный. Имена полей теперь уникальны и не вызовут конфликта при записи в массив $_POST.

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

Примерный алгоритм разбора такого запроса в PHP:

Таким образом, массив $_POST будет содержать следующие значения:

Форма содержит список, в котором мы можем выбрать несколько вариантов. Допустим, мы выбирали Movies, Cooking и Golf. Можно предположить, что при отправке поля будет использован некий разделитель значений. На самом же деле запрос будет выглядеть следующим образом:

Т.е. в браузере мы отправляем одно поле с тремя значениями, но серверная сторона видит это как отправку трех полей, которые содержат по одному значению. Очевидно, что согласно пункту 4 массив $_POST будет содержать только одно последнее значение golf, которое перезапишет первые два. Для решения этой проблемы необходимо воспользоваться советом из пункта 5 и изменить имя тега select на «hobbies[]».

За всё ответит разработчик

Кратко также рассмотрим вторую группу способов отправки форм. Эта группа отличается от первой тем, что созданием, формированием и отправкой запроса занимается непосредственно разработчик. Данная группа имеет лишь отдалённое отношение к рассматриваемой нами теме, так как не имеет жёсткой привязки к HTML-формам: разработчик может включать в запрос и исключать из него любые данные. Способ сериализации полей отличается от полностью произвольного запроса наличием в широко распространённых JS-фреймворках готовых алгоритмов, которые берут на себя большую часть работы. Эти способы удобны при отправке данных форм с использованием Ajax.

Рассмотрим небольшой пример использования JS-библиотеки jQuery для формирования и отправки формы таким способом.

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

Почему из пяти полей формы в запрос включаются только два? Поле email не включается, т.к. находится в отключённом состоянии (атрибут disabled), а поля photo и submit – т.к. метод serialize() данной JS-библиотеки не включает файлы и кнопки в набор полей при формировании строки запроса.

Далее создаём Ajax-запрос с определёнными параметрами и отправляем нашу форму в виде полученной ранее строки. Тут важно понять, что при использовании данного способа от HTML-формы требуется только набор полей с их именами и значениями, все остальные параметры запроса определяет непосредственно разработчик. Таким образом, атрибуты action, method и enctype тега form игнорируются: при вызове метода ajax() мы явно указываем, что данные будут переданы методом POST в обработчик «server.php», а кодирование полей в данном методе по умолчанию – «application/x-www-form-urlencoded».

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

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

К чему вся эта статья?

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

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

HTML Forms

An HTML form is used to collect user input. The user input is most often sent to a server for processing.

Example

The <form> Element

The HTML <form> element is used to create an HTML form for user input:

The <form> element is a container for different types of input elements, such as: text fields, checkboxes, radio buttons, submit buttons, etc.

All the different form elements are covered in this chapter: HTML Form Elements.

The <input> Element

The HTML <input> element is the most used form element.

An <input> element can be displayed in many ways, depending on the type attribute.

Here are some examples:

Type	Description
<input type="text">	Displays a single-line text input field
<input type="radio">	Displays a radio button (for selecting one of many choices)
<input type="checkbox">	Displays a checkbox (for selecting zero or more of many choices)
<input type="submit">	Displays a submit button (for submitting the form)
<input type="button">	Displays a clickable button

All the different input types are covered in this chapter: HTML Input Types.

Text Fields

The <input type=»text»> defines a single-line input field for text input.

Example

A form with input fields for text:

This is how the HTML code above will be displayed in a browser:

Note: The form itself is not visible. Also note that the default width of an input field is 20 characters.

The <label> Element

Notice the use of the <label> element in the example above.

The <label> tag defines a label for many form elements.

The <label> element is useful for screen-reader users, because the screen-reader will read out loud the label when the user focuses on the input element.

The <label> element also helps users who have difficulty clicking on very small regions (such as radio buttons or checkboxes) — because when the user clicks the text within the <label> element, it toggles the radio button/checkbox.

The for attribute of the <label> tag should be equal to the id attribute of the <input> element to bind them together.

Radio Buttons

The <input type=»radio»> defines a radio button.

Radio buttons let a user select ONE of a limited number of choices.

Example

A form with radio buttons:

<p>Choose your favorite Web language:</p>

This is how the HTML code above will be displayed in a browser:

Choose your favorite Web language:

HTML
CSS
JavaScript

Checkboxes

The <input type="checkbox"> defines a checkbox.

Checkboxes let a user select ZERO or MORE options of a limited number of choices.

Example

A form with checkboxes:

This is how the HTML code above will be displayed in a browser:

I have a bike
I have a car
I have a boat

The Submit Button

The <input type=»submit»> defines a button for submitting the form data to a form-handler.

The form-handler is typically a file on the server with a script for processing input data.

The form-handler is specified in the form’s action attribute.

Example

A form with a submit button:

This is how the HTML code above will be displayed in a browser:

The Name Attribute for <input>

Notice that each input field must have a name attribute to be submitted.

If the name attribute is omitted, the value of the input field will not be sent at all.

Example

This example will not submit the value of the "First name" input field: