Учебник Express часть 6: Работы с формами

Перевод не завершен. Пожалуйста, помогите перевести эту статью с английского.

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

Prerequisites: Complete all previous tutorial topics, including Express Tutorial Part 5: Displaying library data
Цель: Понять, как писать формы для получения данных от пользователей и обновлять базу данных с этими данными.

Обзор

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

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

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

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

HTML Forms

Первый краткий обзор HTML Forms. Рассмотрим простую HTML-форму с одним текстовым полем для ввода имени некоторой "команды" и связанной с ней меткой:

Simple name field example in HTML form

Определенные в  HTML формы собираются внутри тэга <form>...</form>, содержащего хтя ы один элемент input с type="submit".

<form action="/team_name_url/" method="post">
    <label for="team_name">Enter name: </label>
    <input id="team_name" type="text" name="name_field" value="Default name for team.">
    <input type="submit" value="OK">
</form>

Хотя здесь мы включили только одно (текстовое) поле для ввода имени команды, форма может содержать любое количество других элементов ввода и связанных с ними меток. The field's type attribute defines what sort of widget will be displayed. The name and id of the field are used to identify the field in JavaScript/CSS/HTML, while value defines the initial value for the field when it is first displayed. The matching team label is specified using the label tag (see "Enter name" above), with a for field containing the id value of the associated input.

Input submit будет отображаться в виде кнопки (по умолчанию) - он может быть нажат пользователем, чтобы загрузить данные, содержащиеся в других входных элементов на сервер (в данном случае, только team_name). Атрибуты формы определяют метод HTTP, используемый для отправки данных, и назначение данных на сервере (action):

  • action: ресурс/URL-адрес, по которому данные должны отправляться на обработку при отправке формы. Если это не установлено (или установлено в пустую строку), то форма будет отправлена назад к URL текущей страницы.
  • method: Метод HTTP, используемый для отправки данных: POST or GET.
    • Метод POST должен всегда использоваться, если данные собираются привести к изменению базы данных сервера, потому что это может быть сделано более устойчивым к атакам запроса подделки межсайтового.
    • Метод GET следует использовать только для форм, которые не изменяют пользовательские данные (например, форма поиска). Рекомендуется, когда вы хотите, чтобы иметь возможность делать закладки или поделиться URL.

Form handling process

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

 

Блок-схема процесса обработки запросов формы показана ниже, начиная с запроса страницы, содержащей форму (показана зеленым цветом):

Как показано на диаграмме выше, основные действия, которые необходимо выполнить коду обработки форм:

  1. Отображение формы по умолчанию при первом запросе пользователем.
    • Форма может содержать пустые поля (например, если вы создаете новую запись), или она может быть предварительно заполнена начальными значениями (например, если вы изменяете запись или имеете полезные начальные значения по умолчанию).
  2. Получение данных, отправленных пользователем, обычно в запросе HTTP POST.
  3. Валидация и очистка данных.
  4. Если какие-либо данные недопустимы, повторно отобразите форму—на этот раз с заполненными пользователем значениями и сообщениями об ошибках для проблемных полей
  5. Если все данные верны, выполнить требуемые действия (например, сохранить данные в базе данных, отправьте уведомление по электронной почте, возвращающие результат поиска, загрузить файл и т. д.)
  6. После завершения всех действий перенаправьте пользователя на другую страницу.

Часто код обработки формы реализуется с помощью GET route для начального отображения формы и POST route к тому же пути для обработки проверки и обработки данных формы. Это подход, который будет использоваться в этом уроке!

Сам Express не предоставляет какой-либо конкретной поддержки для операций обработки форм, но он может использовать промежуточное программное обеспечение для обработки POST и GET параметров из формы, а также для проверки/очистки их значений.

Validation and sanitization

Перед сохранением данных формы их необходимо проверить и очистить:

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

В этом уроке мы будем использовать популярный модуль express-validator для проверки и очистки данных формы.

Установка

Установите модуль, выполнив следующую команду в корне проекта

npm install express-validator

Using express-validator

Note: express-validator руководство на Github предоставляет хороший обзор API. Мы рекомендуем вам прочитать это, чтобы получить представление о всех его возможностях (включая создание пользовательских валидаторов). Ниже мы рассмотрим только подмножество, которое полезно для LocalLibrary.

Для того, чтобы использовать валидатор в наших контроллерах, мы должны требовать функции, которые мы хотим использовать из модулей 'express-validator/check' и 'express-validator/filter', как показано ниже:

const { body,validationResult } = require('express-validator/check');
const { sanitizeBody } = require('express-validator/filter');

Есть много доступных функций, позволяющих проверять и очищать данные из параметров запроса, тела, заголовков, файлов cookie и т. д., или все сразу. Для этого урока мы будем использовать bodysanitizeBody, and validationResult (как "требуется" выше).

Функции определяются следующим образом:

  • body(fields[, message]): Задает набор полей в теле запроса (параметр POST) для проверки, а также необязательное сообщение об ошибке, которое может отображаться в случае сбоя тестов. Критерии проверки последовательно связаны с методом body(). Например, первая проверка ниже проверяет, что поле" имя "не пустое и задает сообщение об ошибке" пустое имя", если оно не пустое. Второй тест проверяет, что поле age является допустимой датой, и с помощью optional() указывает, что пустые и пустые строки не пройдут проверку.
    body('name', 'Empty name').isLength({ min: 1 }), 
    body('age', 'Invalid age').optional({ checkFalsy: true }).isISO8601(),
    
    Можно также последовательно подключить различные валидаторы и добавить сообщения, отображаемые при выполнении предыдущих валидаторов.
    body('name').isLength({ min: 1 }).trim().withMessage('Name empty.')
        .isAlpha().withMessage('Name must be alphabet letters.'),
    

    Note: Вы также можете добавить встроенные средства очистки, такие как trim(), как показано выше. Однако средства очитски, применяемые здесь, применяются только к шагу проверки. Если требуется очистить конечный результат, необходимо использовать отдельный метод очистки, как показано ниже.

  • sanitizeBody(fields): Задает поле тела для очистки. затем операции очистки последовательно соединяются с этим методом. Например, операция очистки escape(), описанная ниже, удаляет символы HTML из переменной name, которые могут использоваться в атаках сценариев между сайтами JavaScript.
    sanitizeBody('name').trim().escape(),
    sanitizeBody('date').toDate(),
  • validationResult(req): Запускает проверку, делая ошибки доступными в виде объекта результата проверки. Это вызывается в отдельном обратном вызове, как показано ниже:
    (req, res, next) => {
        // Extract the validation errors from a request.
        const errors = validationResult(req);
    
        if (!errors.isEmpty()) {
            // There are errors. Render form again with sanitized values/errors messages.
            // Error messages can be returned in an array using `errors.array()`.
            }
        else {
            // Data from form is valid.
        }
    }
    Мы используем метод isEmpty() результата проверки, чтобы проверить, были ли ошибки, и его метод array (), чтобы получить набор сообщений об ошибках. Дополнительные сведения см. в разделе API результатов проверки.

Цепочки проверки и очистки являются промежуточными запросами, которые должны быть переданы обработчику Express -маршрута (мы делаем это косвенно, через контроллер). При запуске промежуточного по каждый валидатор / средства очистки выполняется в указанном порядке..

Мы рассмотрим некоторые реальные примеры, когда мы реализуем LocalLibrary формы ниже.

Form design

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

  • Создайте объект, если связанные с ним объекты еще не существуют (например, книга, в которой не определен объект автора).
  • Удаление объекта, который все еще используется другим объектом (например, удаление жанра, который все еще используется книгой).

Для этого проекта мы упростили реализацию, объявив, что форма может быть только:

  • Создайте объект, используя объекты, которые уже существуют (таким образом, пользователи должны будут создать все необходимые экземпляры автора и жанра, прежде чем пытаться создать любые объекты книги).
  • Удалите объект, если на него не ссылаются другие объекты (например, Вы не сможете удалить книгу, пока не будут удалены все связанные объекты BookInstance).

Note: Более" надежная " реализация может позволить создавать зависимые объекты при создании нового объекта и удалять любой объект в любое время (например, путем удаления зависимых объектов или путем удаления ссылок на удаленный объект из базы данных).

Routes

Чтобы реализовать наш код обработки форм, нам понадобятся два маршрута с одинаковым шаблоном URL. Первый (GET) маршрут используется для отображения новой пустой формы создания объекта. Второй маршрут (POST) используется для проверки введенных пользователем данных, а затем сохранения информации и перенаправления на страницу сведений (если данные верны) или повторного отображения формы с ошибками (если данные неверны).

Мы уже создали маршруты для всех страниц создания нашей модели в  /routes/catalog.js (in a previous tutorial).  Например, жанровые маршруты показаны ниже:

// GET request for creating a Genre. NOTE This must come before route that displays Genre (uses id).
router.get('/genre/create', genre_controller.genre_create_get);

// POST request for creating Genre.
router.post('/genre/create', genre_controller.genre_create_post);

Express forms subarticles

The following subarticles will take us through the process of adding the required forms to our example application. You need to read and work through each one in turn, before moving on to the next one.

  1. Create Genre form — Defining our page to create Genre objects.
  2. Create Author form — Defining a page for creating Author objects.
  3. Create Book form — Defining a page/form to create Book objects.
  4. Create BookInstance form — Defining a page/form to create BookInstance objects.
  5. Delete Author form — Defining a page to delete Author objects.
  6. Update Book form — Defining  page to update Book objects.

Challenge yourself

Implement the delete pages for the Book, BookInstance, and Genre models, linking them from the associated detail pages in the same way as our Author delete page. The pages should follow the same design approach:

  • If there are references to the object from other objects, then these other objects should be displayed along with a note that this record can't be deleted until the listed objects have been deleted.
  • If there are no other references to the object then the view should prompt to delete it. If the user presses the Delete button, the record should then be deleted.

A few tips:

  • Deleting a Genre is just like deleting an Author as both objects are dependencies of Book (so in both cases you can delete the object only when the associated books are deleted).
  • Deleting a Book is also similar, but you need to check that there are no associated BookInstances.
  • Deleting a BookInstance is the easiest of all, because there are no dependent objects. In this case you can just find the associated record and delete it.

Implement the update pages for the BookInstance, Author, and Genre models, linking them from the associated detail pages in the same way as our Book update page.

A few tips:

  • The Book update page we just implemented is the hardest! The same patterns can be used for the update pages for the other objects.
  • The Author date of death and date of birth fields, and the BookInstance due_date field are the wrong format to input into the date input field on the form (it requires data in form "YYYY-MM-DD"). The easiest way to get around this is to define a new virtual property for the dates that formats the dates appropriately, and then use this field in the associated view templates.
  • If you get stuck, there are examples of the update pages in the example here.

Summary

Express, node, and third party packages on NPM provide everything you need to add forms to your website. In this article you've learned how to create forms using Pug, validate and sanitize input using express-validator, and add, delete, and modify records in the database.

You should now understand how to add basic forms and form-handling code to your own node websites!

See also

In this module

 

Метки документа и участники

Внесли вклад в эту страницу: MariyaSka
Обновлялась последний раз: MariyaSka,