--- title: 'Express チュートリアル Part 6: フォームの操作' slug: Learn/Server-side/Express_Nodejs/forms translation_of: Learn/Server-side/Express_Nodejs/forms ---

{{PreviousMenuNext("Learn/Server-side/Express_Nodejs/Displaying_data", "Learn/Server-side/Express_Nodejs/deployment", "Learn/Server-side/Express_Nodejs")}}

このチュートリアルでは、Pug を使用して Express で HTML フォームを操作する方法、特にデータベースからドキュメントを作成、更新、削除するためのフォームを作成する方法を説明します。

前提条件:	Express チュートリアル Part 5: ライブラリデータの表示など、これまでのチュートリアルのトピックをすべて完了してください。
目標:	ユーザからデータを取得するためのフォームの作成方法を理解し、このデータでデータベースを更新する。

概要

HTMLフォームとは、サーバーに送信するためにユーザーから情報を収集するために使用できる Web ページ上の 1 つ以上のフィールド/ウィジェットのグループのことです。テキストボックス、チェックボックス、ラジオボタン、日付選択など、さまざまなタイプのデータを入力するのに適したフォーム入力が用意されているので、フォームを使えばユーザーからの入力を柔軟に収集することが出来ます。また、フォームはサーバとデータを共有するための比較的安全な方法でもあり、クロスサイトリクエストフォージェリ保護機能を使ってPOSTリクエストでデータを送信することができます。

フォームを扱うのは複雑です。開発者はフォーム用の HTML を書き、サーバー上で入力されたデータを検証して特殊文字を置換し、無効なフィールドをユーザーに知らせるためにエラーメッセージを表示してフォームを再度表示し、送信が成功したときにデータを処理し、最後に成功を示す何らかの方法でユーザーに応答しなければなりません。

このチュートリアルでは、上記の操作をExpressで実行する方法を紹介します。途中で、サンプルとして地域図書館のウェブサイトを拡張して、ユーザーがライブラリからアイテムを作成、編集、削除できるようにします。

Note: サンプルとして準備されている地域図書館のウェブサイトは認証済みユーザのみに閲覧を制限する方法については書いてないので、現時点ではどのユーザでもデータベースに変更を加えることができます。

HTMLフォーム

最初にHTMLフォームの簡単な概要を説明します。ある「チーム」の名前とそれに関連するラベルを入力するための単一のテキストフィールドを持つシンプルな HTML フォームを考えてみましょう。

Simple name field example in HTML form

フォームは HTML で <form>...</form> タグ内の要素の集合として定義され、type="submit" のinput要素を少なくとも 1 つ含みます。

<form action="/team_name_url/" method="post">
    <label for="team_name">名前を入力してください: </label>
    <input id="team_name" type="text" name="name_field" value="デフォルトのチーム名.">
    <input type="submit" value="OK">
</form>

ここではチーム名を入力するための1つのテキストフィールドだけを含んでいますが、フォームは他の入力要素とそれに関連したラベルをいくつでも含むことができます。フィールドのtype属性はどのような種類のウィジェットが表示されるかを定義します。フィールドのnameとidはJavaScript/CSS/HTMLでフィールドを識別するために使われ、valueはフィールドが最初に表示されるときの初期値を定義します。マッチングするチームのラベルは、labelタグ（上記の「名前を入力してください」を参照）を使用して指定され、forフィールドには関連するinputタグのid値が含まれます。

submit inputタグは標準ではボタンとして表示されます。このボタンは、他のinput要素に含まれるデータをサーバーにアップロードするためにユーザーが押すことができます(この例だとteam_nameだけ)。フォーム属性はデータを送信するために使用されるHTTP methodとサーバー上のデータの送信先(action)を定義します。

action: フォームが送信されたときに処理のためにデータが送信されるURLです。これが設定されていない場合(または空の文字列が設定されている場合)、フォームは現在のページURLに戻って送信されます。
method: データを送信するために使用される HTTP メソッド: POST または GET.
- POSTメソッドは、データがサーバのデータベースに変更をもたらす場合は、常に使用されるべきです。なぜならクロスサイトフォージェリ要求攻撃に対してより耐性を持たせることができるからです。
- GETメソッドは、ユーザーデータを変更しないフォーム（検索フォームなど）にのみ使用してください。URLをブックマークや共有できるようにしたい場合におすすめです。

フォーム処理工程

フォームの処理はモデルに関する情報を表示するために学んだのと同じテクニックをすべて使います: ルートはリクエストをコントローラ関数に送り、モデルからのデータの読み込みを含む必要なデータベースアクションを実行し、HTMLページを生成して返します。さらに複雑なのは、サーバーがユーザーによって提供されたデータを処理し、何か問題があればエラー情報とともにフォームを再表示する必要があるということです。

フォームを含むページのリクエスト（緑色で示されている）から始まる、フォームリクエストを処理するためのプロセスフローチャートを以下に示す。

上の図のように、フォーム処理のコードが必要とする主なものは以下の通りです。

ユーザーが最初に要求したときにデフォルトのフォームを表示します。
- フォームには空白のフィールドが含まれていたり (新しいレコードを作成している場合など)、初期値があらかじめ入力されていたり (レコードを変更している場合や、デフォルトの初期値がある場合など) します。
ユーザーから送信されたデータを、通常はHTTP POSTリクエストで受信します。
データを検証し、ハッキング防止のために特殊文字を置換(サニタイズ)します。
データが無効な場合は、ユーザーが入力した値と問題のあるフィールドのエラーメッセージをフォームに再表示します。
すべてのデータが有効な場合、必要なアクションを実行します（例：データベースにデータを保存する、通知メールを送信する、検索結果を返す、ファイルをアップロードするなど）。
すべてのアクションが完了したら、ユーザーを別のページにリダイレクトします。

多くの場合、フォーム処理コードは、フォームの初期表示のためのGETルートと、フォームデータの検証と処理のための同じパスへのPOSTルートを使用して実装されています。これがこのチュートリアルで使用されるアプローチです。

Express 自体はフォーム操作のための特別なサポートを提供していませんが、ミドルウェアを使用してフォームからの POST や GET パラメータを処理したり、それらの値を検証/サニタイズしたりすることができます。

検証とサニタイズ

フォームからのデータが保存される前に、それは検証され、サニタイズされなければなりません。

入力された値が各フィールドに対して適切であるか（正しい範囲、フォーマットなど）、およびすべての必須フィールドに対して値が提供されているかどうかを確認します。
サニタイズは、悪意のあるコンテンツをサーバーに送信するために使用される可能性のあるデータ内の文字を削除したり、置換したりします。

このチュートリアルでは、人気のある express-validator モジュールを使ってフォームデータの検証とサニタイズを行います。

インストール

プロジェクトのルートで以下のコマンドを実行してモジュールをインストールします。

npm install express-validator

express-validatorの使用

Note: Githubのexpress-validatorガイドにAPIの概要が書かれています。(カスタムバリデータの作成を含む) すべての機能を知るには、これを読むことをお勧めします。以下では、サンプルの「地域図書館」にとって有用なサブセットだけを取り上げます。

コントローラでバリデータを使うには、以下のように 'express-validator/check' と 'express-validator/filter'モジュールから使いたい関数を要求(require)しなければなりません。

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

多くの関数が用意されており、リクエストパラメータ、body、ヘッダー、Cookieなどのデータをチェックしてサニタイズすることができますし、一度にすべてのデータをチェックしてサニタイズすることもできます。このチュートリアルでは、主にbody、sanitizeBody、validationResultを使用します。

機能は以下のように定義されています。

body(fields[, message]): テストに失敗した場合に表示されるオプションのエラーメッセージとともに検証するリクエストボディ (POSTパラメータ) のフィールドのセットを指定します。検証基準は、body()メソッドにデイジーチェーンで接続されています。例えば、以下の最初のチェックでは「name」フィールドが空でないことをテストし、空の場合は「Empty name」というエラーメッセージを設定します。2 番目のテストでは、年齢フィールドが有効な日付であるかどうかをチェックし、optional() を使用して null や空の文字列を指定しても検証に失敗しないようにしています。
```
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() サニタイズ操作は、JavaScript のクロスサイトスクリプティング攻撃で使用される可能性のある HTML 文字（例えば「'」、「"」、「&」など）を name 変数から削除します。
```
sanitizeBody('name').trim().escape(),
sanitizeBody('date').toDate(),
```

validationResult(req): Runs the validation, making errors available in the form of a validation result object. This is invoked in a separate callback, as shown below:

(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.
    }
}

We use the validation result's isEmpty() method to check if there were errors, and its array() method to get the set of error messages. See the Validation Result API for more information.

The validation and sanitization chains are middleware that should be passed to the Express route handler (we do this indirectly, via the controller). When the middleware runs, each validator/sanitizer is run in the order specified.

We'll cover some real examples when we implement the LocalLibrary forms below.

Form design

Many of the models in the library are related/dependent—for example, a Book requires an Author, and may also have one or more Genres. This raises the question of how we should handle the case where a user wishes to:

Create an object when its related objects do not yet exist (for example, a book where the author object hasn't been defined).
Delete an object that is still being used by another object (so for example, deleting a Genre that is still being used by a Book).

For this project we will simplify the implementation by stating that a form can only:

Create an object using objects that already exist (so users will have to create any required Author and Genre instances before attempting to create any Book objects).
Delete an object if it is not referenced by other objects (so for example, you won't be able to delete a Book until all associated BookInstance objects have been deleted).

Note: A more "robust" implementation might allow you to create the dependent objects when creating a new object, and delete any object at any time (for example, by deleting dependent objects, or by removing references to the deleted object from the database).

Routes

In order to implement our form handling code, we will need two routes that have the same URL pattern. The first (GET) route is used to display a new empty form for creating the object. The second route (POST) is used for validating data entered by the user, and then saving the information and redirecting to the detail page (if the data is valid) or redisplaying the form with errors (if the data is invalid).

We have already created the routes for all our model's create pages in /routes/catalog.js (in a previous tutorial). For example, the genre routes are shown below:

// 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 sub articles 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.

Create Genre form — Defining a page to create Genre objects.
Create Author form — Defining a page to create Author objects.
Create Book form — Defining a page/form to create Book objects.
Create BookInstance form — Defining a page/form to create BookInstance objects.
Delete Author form — Defining a page to delete Author objects.
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.