Rivalry2

HTML Diff

0 added 0 removed

Original 2026-01-01

Modified 2026-02-26

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

2 <ul><li>Как работают соответствующие HTML-теги</li>

3 <li>Как отправляются формы по HTTP</li>

4 <li>Как происходит обработка на стороне сервера</li>

5 <li>Как работает валидация и вывод ошибок</li>

6 </ul>Все это мы изучим в ближайшее время.

7 <h2>Вывод формы</h2>

8 За вывод формы и ее обработку должны отвечать два разных маршрута - а значит, еще и два обработчика. Рассмотрим примеры маршрутов для создания нового пользователя:

9 <ul><li>GET/users/build- страница с формой, которую заполняет пользователь. Эта форма отправляет POST-запрос на адрес/users, указанный в атрибуте action</li>

10 <li>POST/users- маршрут, обрабатывающий данные формы</li>

11 </ul>Для нашей задачи мы будем использовать класс пользователя. Он может выглядеть так:

12 Добавим обработчик маршрута/users/build, который выводит форму добавления пользователя:

13 Создадим форму в файлеsrc/main/jte/users/build.jte:

14 Запустим сервер и убедимся, что форма выводится по адресу/users/build. Если ее заполнить и попытаться отправить, то браузер сформирует следующий HTTP-запрос:

15 В примере выше мы видели работу с HTTP, но на практике все устроено немного по-другому. Не стоит передавать электронную почту, пароль и другие чувствительные данные по обычному HTTP-протоколу, потому что так данные легко перехватить и использовать не по назначению.

16 Именно поэтому современные сайты обычно работают по протоколу HTTPS, который передает данные в зашифрованном виде.

17 <h2>Обработка данных</h2>

18 Форма готова, теперь можно реализовывать ее обработчик. Обработчик формы работает так:

19 <ul><li>Извлекает параметры формы через метод ctx.formParam()</li>

20 <li>Формирует объект пользователя на основе этих параметров</li>

21 <li>Сохраняет объект пользователя в базу данных</li>

22 <li>Выполняет редирект - например, на страницу пользователей</li>

23 </ul>Код обработчика выглядит так:

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

25 <h2>Нормализация данных</h2>

26 Представим, что при регистрации пользователь написал свою почту в произвольном регистре -<a>MYname@example.com</a>вместо<a>myname@example.com</a>. По спецификации, адреса электронной почты не зависят от регистра. Другими словами, если в двух адресах совпадают буквы, то они считаются одним и тем же адресом.

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

28 <ul><li>Пользователь сможет зарегистрировать несколько аккаунтов на один и тот же адрес почты, просто вводя адрес в разном регистре</li>

29 <li>Пользователь не сможет зайти на сайт, если введет почту не в том регистре, который использовал при регистрации</li>

30 </ul>Чтобы этого не происходило, введенные пользователями данные проходятнормализацию. В случае почты мы приводим ее к нижнему регистру:

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

32 А вот для имени и адреса почты такое недопустимо. Поэтому лучше обрезать концевые пробелы для надежности: