新しいエンティティコンセプトを使用したDrupal 7の開発

この記事で検討するエンティティ（エンティティ）の概念は、Drupal 7で提示される新規性の1つです。提案されたアプローチの全体的な新規性を実現するには、歴史を少し脱線し、Drupal 6のすべてを思い出してください。

何と一緒に食べるの？

Drupalで作成されたすべてのモジュールは、条件付きで2つのカテゴリに分類できます。 最初のモジュールは、実際に新しいデータ型を宣言せず、すでに定義され保存されているデータを処理するモジュールです。 たとえば、lightbox2モジュールを使用すると、サイト上の画像の表示を変更できます。develモジュールは、開発者に役立つさまざまなユーティリティを提供します。 また、develモジュールはデータベースにいくつかの情報（たとえば、SQLクエリの実行時）を格納しますが、実際には、これを本格的なデータモデルと呼ぶことはできません。

2番目のカテゴリは、新しいタイプのオブジェクトの作成、新しいデータモデルの定義を可能にするモジュールです。 このようなモジュールには、たとえば、webformモジュール（調査フォームの作成を許可）、およびカーネルに含まれるユーザーモジュール（新しいユーザーの作成（登録）、さまざまな操作の実行）が含まれます。



モジュールの開発者が新しいデータ型を宣言する必要がある場合、2つのオプションがあります。 最初のオプションは、データタイプを新しい材料タイプ（ノードタイプ）として定義することです。 2番目のオプションは、すべてをゼロから作成することです。 どちらのアプローチにも長所と短所があります。 2番目のオプションがより柔軟であり、実装に実際に制限を課さないことは明らかです。 最初のオプションは、Node APIが提供する既製のツールにより、より便利で実行が高速です。



ただし、開発のスピードと容易さだけでなく、Drupal 6で作成され、新しいデータモデルを実装する最も深刻なモジュールは、それをノードタイプとして宣言します。 重要な特徴は、タイプに関係なく、すべての材料が特定の一般的な構造と外部相互作用の一般的なスキームを持っていることです。 このアプローチにより、1つのモジュールを記述して、システムに存在するすべてのタイプのマテリアルの機能を拡張できます。 実際、特定の種類のマテリアルの存在を認識していない場合がありますが、同時に、それに影響を与え、操作できるモジュールを作成します。 鮮明な例は、CCKおよびビューモジュールです。



すべては問題ないように見えますが、1つの問題が残っています。 前述したように、ノードタイプを介した実装にはいくつかの制限があり、場合によってはこのアプローチが不便または不可能になります。 特に、Drupal 6のユーザーまたはコメントがコンテンツタイプとして実装されていると想像するのは困難です。 もちろん、ユーザーを素材の形で実装することの可能性または不可能性については、ここでarbitrarily意的に長い議論がありますが、このアプローチはいずれの場合もエレガントで正しいとは言えません。



Drupal 7の登場で何が変わったのですか？ 実際、新しいレベルの抽象化が作成されました。 そして彼の名前はエンティティです。 実際、エンティティは、Drupal 6のノードよりも抽象度が低いレベルです。すぐに、Drupal 7ではノードが消えないことを予約しますが、現在はそれらがエンティティのアドオンになっています。 最良の部分は、Drupal 7のユーザー、コメントなどもエンティティであるということです。 あなたはすでに「箱から出して」の違いを感じることができます。 たとえば、以前は、CCKモジュールを使用して、材料タイプにのみ新しいフィールドを追加できました。 Drupal 7では、ユーザー、コメント、さらには分類タグでも同じことができます。 これは、タグ、マテリアル、コメント、およびユーザーがすべてエンティティのサブクラスであるためです。

検死が表示されます

エンティティシステムの内部構造に関する議論を始める前に、 api.drupal.orgのようなすばらしいリソースを思い出してください。シェイクスピア言語で後述するすべてのインターフェイス、クラス、メソッドにいつでも慣れることができます。



それでは、すべてがどのように機能するかを見てみましょう。 Drupal 7では（後で見られるように）オブジェクト指向プログラミングがより積極的に使用されるようになりましたが、モジュールに新しいエンティティが実装されていることをシステムに通知するには、フックを実装する必要があります。 興味のあるフックはhook_entity_info（）です。 それから、連想配列を返さなければなりません。連想配列のキーは、実装するエンティティの名前になります。 同様に、各エンティティはそのパラメータの配列に対応します。 以下に指定できるパラメーターのリストを示します。

• ラベル：エンティティのいわゆる「人間が読める」タイプ名。 ラベルを翻訳可能にする場合は、t（）でラップする必要があります。
• コントローラークラス：データの読み込みを担当するcounterOllerクラスの名前。 クラスはDrupalEntityControllerInterfaceインターフェースを実装する必要があります。 このパラメーターを指定しない場合、デフォルトのコントローラーであるDrupalDefaultEntityControllerがコントローラーとして使用されます（エンティティコントローラーについては、この記事で後述します）。
• ベーステーブル：エンティティのデータベース内のベーステーブル。 正式には、パラメーターはオプションです。 DrupalDefaultEntityControllerクラスによって使用され、継承されます。 つまり DrupalEntityControllerInterfaceインターフェースを独自の方法で実装し、データベーステーブルからではなく、少なくとも火星衛星からデータを受信できますが、DrupalDefaultEntityControllerまたはその派生物をコントローラーとして使用する場合は、このパラメーターを指定してください。 将来を見据えて、ほとんどの場合、コントローラーはDrupalDefaultEntityControllerまたはEntityAPIControllerなどのより高いレベルのクラス（後述）から継承するのが理にかなっていると言います。
• 改訂テーブル：前のものと似ていますが、この場合は改訂テーブルです。 ここでノードとの類推が正しく追跡されます。 エンティティがさまざまなリビジョンを想定していない場合、パラメーターは省略できます。
• 静的キャッシュ：DrupalDefaultEntityControllerによって使用される別のパラメーター。 ページ要求中の静的エンティティキャッシュを有効にします。 つまり この場合、リクエスト間のキャッシュではなく（データが一定期間キャッシュされ、新しいリクエストごとにキャッシュが期限切れになるまでキャッシュから返される場合）、1つのリクエストのキャッシュについてです。 したがって、クエリパスの本質を変更してからリロードする予定がない場合は、TRUEに設定するのが理にかなっています（デフォルトではTRUEであるため、単にパラメーターを省略します）。
• フィールドキャッシュ：ここでは、フィールド（フィールドAPI）に関連する永続キャッシュについて説明しています。これは、後で示すように、エンティティにアタッチできます。 公式ドキュメントでは、このパラメーターをFALSEに設定することが意味があるのは、エンティティ全体が定数キャッシュの対象である場合のみです。 つまり、必要な理由が正確にわからない場合は、このパラメーターを省略し、デフォルトでTRUEに設定されていることを忘れないでください。
• ロードフック：DrupalDefaultEntityControllerで使用される別のパラメーター。 DrupalDefaultEntityController：attachLoad関数によって呼び出され、他のモジュールがその情報をエンティティに添付できるようにします。 いずれの場合でも、attach_load関数はすべてのエンティティに対してhook_entity_loadを呼び出しますが、指定されたロードフックを使用すると、エンティティに対して別のフック（ノードモジュールのhook_node_loadなど）を呼び出すことができます。
• uriコールバック：エンティティ自体が引数として使用されます。 エンティティのアドレス（パスやオプションなど）のURIを返します。このコンポーネントから、後でuri（）関数を使用してエンティティのアドレスを取得できます。 この関数の定義にはさまざまなアプローチがあります。 特にEntity APIモジュールには、渡されたエンティティの$ entity-> uri（）関数を単に呼び出すentity_class_uri関数があり、エンティティにアドレスを決定する機能を与えます。
• ラベルコールバック：エンティティの名前を取得するために使用されるオプションのパラメーター。 引数として、本質とエンティティのタイプを取ります。 エンティティの名前がこのエンティティの一部のパラメーターと同等である場合（ノードの名前がタイトルフィールドと同等など）、「ラベル」-要素「エンティティキー」（後述）を使用することをお勧めします。 名前が何らかの方法で特別な方法で形成されている場合（たとえば、いくつかのフィールドの組み合わせとして）、「ラベルコールバック」を使用して設定できます。
• フィールド化可能：sayingにあるように、「これが魔法です」。 TRUEに設定し、コントローラーがこの機能を実装する（またはDrupalDefaultEntityControllerから継承される）と想定することにより、DrupalフィールドAPIを使用してエンティティを拡張可能にします（Drupal 7のDrupal 6のCCKアナログはカーネルに統合されます）。 つまり ユーザー、ノードのタイプ、タグなど、さまざまなフィールドをエンティティに添付できます。
• 翻訳：詳細に進むことなく-このフィールドを使用すると、エンティティとそれに関連付けられたフィールドを翻訳可能にすることができます。 空でない場合、連想配列は値として示されます。キーは翻訳機能を提供するモジュールの名前であり、値は翻訳に必要なあらゆる種類の情報構造です。
• エンティティキー：フィールドAPIで使用されるパラメーター。 次の要素を含む可能性のある連想配列：
• -id：エンティティの一意のプライマリ識別子を含むエンティティフィールド。 fieldableがTRUEに設定されている場合は必須です。 値は正の整数でなければなりません。
• -リビジョン：リビジョンIDを含むパラメーターの名前。 フィールドAPIは、タイプ内のすべてのエンティティに一意のリビジョンIDがあると想定しています。 エンティティがバージョン（改訂）モデルを実装していない場合、パラメーターは省略できます。
• -bundle：エンティティが属するバンドル（サブタイプ）を示すパラメーター。 各バンドルには、独自のフィールドセットがあります。 ここで、良い例はノードのタイプです。各タイプに対して独自のフィールドを指定できます（最終的には、すべてのタイプが1つのエンティティであるという事実にもかかわらず）。 エンティティタイプにこのような機能を実装する予定がない場合（異なるバンドルや異なるフィールドセットを使用する予定がない場合）、このパラメーターを省略できます。 次に、エンティティタイプの名前が自動的にパラメータとして使用されます。
• -ラベル：エンティティの名前を示すパラメーター。 タイトルを動的に形成する必要がある場合は、前述のラベルコールバックパラメーターを使用します。
• バンドル：実際にエンティティのタイプのバンドル（サブタイプ）のセットを定義します。 キーの連想配列は、バンドルのマシン名です（「エンティティキー」パラメーターで定義された「バンドル」フィールドに格納される形式）。 バンドルの名前は、次のキーを使用して連想配列に関連付けられます。
• -label：「人間が読める」はバンドルの名前です。 いつものように、名前を翻訳可能にしたい場合はt（）でラップします。
• -uriコールバック：エンティティタイプの「uriコールバック」と同じ、バンドルのみ。 これらの両方が指定されている場合、コールバックがバンドルに使用されます。
• -admin：Field APIがエンティティ管理ページにそのページを埋め込むことを可能にする情報を含む配列。
• -path：バンドル管理ページへのパス。 パスにプレースホルダーが含まれる場合は、「バンドル引数」と「実際のパス」の値も指定する必要があります（以下で説明します）。
• --バンドル引数：パス内のスタブの位置。 原則は、メニューパスを使用する場合と同じです。
• --実パス：スタブなしのバンドル管理ページへのパス。 リンクの生成に使用されます。
• --アクセスコールバック：hook_menu（）と同じ。 空白のままにすると、user_access（）が使用されます。
• --アクセス引数：hook_menu（）と同じです。
• 表示モード：エンティティを表示するさまざまな方法（タイプ）。 良い例は、ノードが完全でティーザーです。 マシンビュー名がキーとして使用される連想配列。 デフォルトでは、各エンティティにはデフォルトのビューがあります。 TRUEがビューパラメータの「カスタム設定」に設定されている場合、他のすべてのビューはデフォルト値を継承できます。 各ビューは、次のキーを持つ配列です。
• -ラベル：「人間が読める」ビュー名。 いつものように、名前を翻訳可能にしたい場合はt（）でラップします。
• -カスタム設定：厳密に言えば、このオプションは主にフィールドに適用されます。 FALSE（デフォルト値）に設定すると、最初はビューはデフォルトビューからフィールドを表示するための設定を継承します。 次に、フィールドUIを使用して設定を変更できます。

これは実際には、エンティティタイプに指定できるすべてのパラメーターです。 EntityAPIControllerなどのDrupalDefaultEntityControllerのアドオンには、追加のパラメーターを使用する必要があることに注意してください。 たとえば、EntityAPIControllerは「エンティティクラス」パラメーターを使用します。 この可能性は、entity_get_info関数（$ entity_type = NULL）のおかげで達成されます。これにより、目的のタイプのエンティティに関するデータを取得できます。

エンティティコントローラー

ここで、「コントローラークラス」パラメーターで定義されているエンティティコントローラーについて説明します。 実際、コントローラーはエンティティのデータを管理する方法です。 私がOOPで気に入っているのは、コードをより効率的にするだけでなく、その内部のプロセスを理解しやすくすることです。 コントローラーの動作を理解するために、下からレビューを開始します。 定義により、 DrupalEntityControllerInterfaceインターフェースを実装するパラメーターは、「コントローラークラス」 パラメーターで指定する必要があります 。 そして、エンティティの概念は明らかに複雑ですが、このインターフェースは驚くほどミニマルです。 実装のクラスに3つのメソッドのみが存在することを前提としています。

DrupalEntityControllerInterface :: load-1つ以上のエンティティをロードします。 エンティティIDの配列を最初の引数としてロードします。 2番目の引数として、 'field' => 'value'という形式の特定の条件の配列を取ります。

DrupalEntityControllerInterface :: resetCache-すべてのエンティティ（引数が指定されていない場合）または選択されたエンティティセット（対応するid配列が引数として渡されている場合）の静的キャッシュをクリア（フラッシュ）します

DrupalEntityControllerInterface :: __ construct-コンストラクター。 単一の引数として、コントローラーのインスタンスを作成するエンティティのタイプを受け入れます。 したがって、コントローラーが作成されているエンティティのタイプがわかっている場合、entity_get_info（$ entity_type）を使用してこのタイプのパラメーターを取得し、コントローラーの作成されたインスタンスをカスタマイズできます。



これが実際にクラスに実装する必要があるすべてのメソッドであり、エンティティコントローラーと呼ばれる完全な権利を持っています。 ただし、ほとんどの場合、インターフェイスをゼロから実装するのではなく、 DrupalDefaultEntityControllerクラスからコントローラークラスを継承することは理にかなっています。

DrupalDefaultEntityControllerは何を提供しますか？

1. エンティティタイプの「ベーステーブル」と「リビジョンテーブル」のパラメータで指定されたデータベーステーブルから、タイプに関係なくエンティティをロードする機能。
2. エンティティタイプのfieldableパラメータがTRUEに設定されている場合、Field APIを使用してエンティティをエンティティにアタッチします。
3. エンティティを効率的にロードする機能。 このクラスは静的キャッシュをサポートしています。 （本質的には、DrupalEntityControllerInterfaceインターフェースのresetCacheメソッドは、静的キャッシュをエンティティコントローラーに実装する必要があることを示唆しています）。

したがって、DrupalDefaultEntityControllerは、エンドユーザー向けの機能の実装を目標として設定せず、開発者に出発点を提供するだけです。 さらに、エンティティが何らかの方法でCRUD（読み取り、更新、削除の作成）の概念を実装する必要がある場合、エンティティAPIモジュールで提示されるより高いレベルのクラス-EntityAPIControllerからコントローラーを継承することは理にかなっています。 ただし、Entity APIの操作の原則を考慮することは、この記事の範囲外であり、別の機会に専念します。