コンテンツモデル
このページで分かること
- コレクション・フィールド・エントリーの関係と、どのエントリーにもEmDashが持たせる標準の情報、エントリーをゴミ箱に移す操作とフィールド・コレクションの削除の違い
- 管理画面の「コンテンツタイプ」とシードファイルという、同じモデルを管理する2つの方法
- 既存のコンテンツがあるモデルを変更するときの注意点と、モデルから生成されるTypeScriptの型
このページの目次
コンテンツモデルは、サイトが保存する情報を表します。EmDashでは、モデルはコレクションとフィールドで構成されます。データベースがそのモデルを保存し、管理画面はそれをもとに、編集者が使うフォームを組み立てます。
コレクション、フィールド、エントリー
コレクション（collection）は、Posts、Products、Authorsのようなコンテンツの種類です。フィールド（field）は、タイトル、本文、価格、執筆者への参照のような、そのコンテンツが持つ1つ1つの情報です。エントリー（entry）は、コレクションに保存された1件の項目です。
たとえば、Postsコレクションは次のフィールドを持てます。
Posts
├── Title short text, required
├── Excerpt long text, optional
├── Content rich text, optional
└── Featured image image, optional
EmDashは、どのエントリーにも必要な情報も管理します。ID、公開用のスラッグ、公開の状態、執筆者、作成日時と更新日時、ロケール、リビジョンへの参照などです。取得結果では、この標準の情報が、コレクションに定義したフィールドと一緒に返されます。
エントリーを削除すると、削除日時が設定され、エントリーはゴミ箱に移ります。誰かがゴミ箱から完全に削除するまで、管理者はそのエントリーを復元できます。このエントリーの操作は、フィールドやコレクションの削除とは別物です。フィールドやコレクションの削除はスキーマを変更し、保存されたデータを消します。
やさしい解説
WordPressの「投稿タイプ」にあたるのがコレクション、「投稿メタ」にあたるのがフィールドです。1本のブログ記事のように、コレクションに保存された1件のコンテンツをエントリーと呼びます。WordPressの投稿と同じく、エントリーを削除するとまずゴミ箱に移り、完全に削除するまでは復元できます。ただし、フィールドやコレクションそのものを削除すると、保存されていた値は消えてしまいます。
1つのモデルと、それを管理する2つの方法
管理者は、管理画面の「コンテンツタイプ」でコレクションを作成・編集できます。EmDashはデータベースのスキーマを更新し、コンテンツの編集画面は、次にそのコレクションを読み込むときから変更を反映します。
シードファイルは、初期のモデルをJSONで記述します。テンプレートは、セットアップ中にシードを使ってコレクションやそのほかのサイトのデータを作成します。チームでシードをバージョン管理しておき、別の環境を作るときに適用することもできます。管理画面とシードは、別々のモデルを作るのではありません。どちらも、対象のデータベースに保存されたモデルを変更します。
次のシードの一部は、Postsの例の4つの独自のフィールドを定義しています。
{
"version": "1",
"collections": [
{
"slug": "posts",
"label": "Posts",
"labelSingular": "Post",
"fields": [
{
"slug": "title",
"label": "Title",
"type": "string",
"required": true
},
{ "slug": "excerpt", "label": "Excerpt", "type": "text" },
{ "slug": "content", "label": "Content", "type": "portableText" },
{ "slug": "featured_image", "label": "Featured Image", "type": "image" }
]
}
]
}
競合したときの扱いと、シードに含められるそのほかのオブジェクト（設定、タクソノミー、メニュー、ウィジェットエリア、リダイレクト、サンプルコンテンツなど）については、シードファイル形式を参照してください。
やさしい解説
WordPressでは、投稿タイプやカスタムフィールドをテーマやプラグインのコードで登録します。EmDashでは、コレクションとフィールドを管理画面の「コンテンツタイプ」で作るか、シードファイル（JSON）に書いてセットアップ時に適用します。どちらの方法でも、変更されるのはデータベースに保存された1つのモデルです。シードファイルをGitで管理しておくと、別の環境にも同じモデルを作れます。
既存のコンテンツがあるモデルの変更
コレクションを追加すると、新しいエントリーを入れる空の場所ができます。任意のフィールドを追加すると、すべてのエントリーにそのフィールドが加わりますが、既存のエントリーには、編集者か移行処理が値を入れるまで値がありません。フィールドを追加するときに、デフォルト値で最初の値を入れておくこともできます。
ラベル、説明、バリデーションのルール、検索の設定、フィールドの順序は、フィールドを作り直さずに更新できます。コレクションとフィールドのスラッグは、変わらない識別子です。管理画面は作成時にスラッグを設定し、あとから名前を変える手段は用意していません。
本番で使っているモデルを変更する前に、デプロイ済みサイトのスキーマの変更を読んでください。
TypeScriptの型宣言
EmDashは、データベースにあるモデルからTypeScriptの型宣言を生成できます。型宣言は、公開されている取得関数にコレクション名とフィールドの形を加えます。そのため、posts を取得すると、返されるエントリーの data.title、data.content などのフィールドをTypeScriptが把握できます。
ローカルでの開発中は、Astroのインテグレーションが emdash-env.d.ts を書き出し、スキーマの変更後に更新します。このファイルは生成される出力なので、型宣言ではなくコンテンツモデルのほうを編集します。リモートでの作業の流れでは、emdash types を実行して、選択したEmDashのサイトから .emdash/types.ts を書き出せます。そのファイルが表すモデルを変更したら、ファイルを生成し直します。
生成された型はコードを現在のスキーマに合わせるのに役立ちますが、保存されたコンテンツを移行するものではありません。モデルの変更と、必要なコンテンツの移行は、引き続き別々の操作です。
関連する概念
コレクションの機能とフィールドの選び方は、コレクションとフィールドを読んでください。編集画面と権限の仕組みは、管理画面を読んでください。