コア分類モジュールまたはエンティティ参照モジュールのどちらを使用するかを決定する方法を知りたいですか？

以前はエンティティ参照モジュールを使用していませんでしたが、10〜15のWebサイトで分類法モジュール（およびいくつかの関連モジュール）を使用しました。

分類法モジュールの代わりに参照ベースのモジュールを使用する利点と欠点は何ですか？

最近、雑誌のアーカイブサイトを作り始めました。

雑誌はたくさんあります。これらの雑誌には問題があります。各号には記事があります。

ここで最も小さい（そして最も深い）部分は記事です。

論文

• ページ番号（範囲）：
• 題名：
• 著者：
• 記事タイプ：
• キーワード：
• マガジン：
• 問題：

問題

• 発行番号：
• 表紙画像：
• 日付（公開）：
• マガジン：

マガジン

• 説明：
• 表紙画像：

ここでは、このWebサイトを実装する（少なくとも）2つの方法があります。

1.呼び出されるコンテンツタイプがarticleあり、他のすべて（問題、雑誌、著者）は分類用語（階層的）になります。発行と雑誌などの間に階層があります。

2.記事、号、雑誌、著者など、多くのコンテンツタイプがあります。記事を作成しながら; 号、雑誌、著者などを参考にすることができます。

したがって、理論的には両方の方法が非常に似ているように見えます。

同様の状況に直面した人はいませんか。どの方法をお勧めしたのですか、なぜですか。

問題に対する他の解決策もあります。

フィールドコレクション

あなたは使用することができますフィールドコレクションとフィールドコレクションビューの内容を保存し、整理するためにモジュールを。このアプローチを使用するIssueと、およびMagazineはフィールドコレクションタイプになりIssue、はのフィールドでArticleありMagazine、のフィールドですIssue。私はそのような構造を実装した経験があります。私の場合、要件はLibrary本（タイトル、出版社、および...フィールドを含む）を含む必要があり、すべての本には複数のボリューム（ページ数、翻訳者、...）が含まれ、各ボリュームには他のアイテムも無制限に含まれています（本の間で同じではないいくつかのページのスキャンのように）。

私はこれをフィールドコレクションアプローチを使用して実装しました。すべてのフィールドコレクションの個々のアイテムを編集するためのリンクを簡単に作成でき、フィールドコレクションのアイテムでフィルタリングすることもできます。フィールドコレクションビューでの作業方法を示す、フィールドコレクションの値でビューのアイテムをグループ化するための回答を投稿しました

エンティティビューの添付ファイル

EVAモジュールとも呼ばれます。

「Eva」は「Entity Views Attachment」の略です。ビューの出力を任意のDrupalエンティティのコンテンツに添付できるようにするビュー表示プラグインを提供します。ノードまたはコメントの本文、ユーザーアカウントのプロファイル、または分類用語のリストページは、すべてエンティティコンテンツの例です。

EVAを使用して、特定のコンテンツのフィールド値のみを表示し、フィールドの表示とフォーマットの柔軟性を驚くほど制御できます。たとえば、特別な方法で2つのフィールドを連結したい場合があります。フィールドをEVAディスプレイに追加し、コンテキストフィルターをNIDに設定し、グローバル：テキストフィールドを追加し、トークンを使用してフィールドをHTMLでフォーマットできます。グローバル：テキストフィールドでフィールドを一緒に使用する場合は、フィールドを表示から除外することを忘れないでください。例：都市、州、郵便番号のフィールドがあるとします。これらをビューのグローバル：テキストフィールドで組み合わせて、「市、州のZIP」として表示できます。コンテンツタイプの表示を管理する場合は、作成したばかりのEVAを表示に追加します。タイプが表示されるノードは常にそのnidをEVAに渡し、EVAは選択したフィールドを返します。必要に応じてフォーマットします。（ソース：EVAおよびエンティティー参照の使用例のハウツー）

このモジュールは完璧です。コンテンツタイプのノードにフィールドとしてビューをアタッチします。このモジュールを使用してを作成しましたAlbum。アルバムにはsinger（それぞれについての情報songsが含まれています）、ファイル、タイトル、レートなどが含まれています。そこで、タイプEVAのビューを作成し、それをノードに接続しました。したがって、すべてのSingerのノードページに、ノードから適切な情報を取得するこのビューを表示しました。エンティティ参照付きのビューは、このモジュールの使用方法の完全なチュートリアルです。

分類用語とエンティティリファレンス

私はあなたが読むことをお勧め実体参照対の分類をし、タームリファレンスの上にエンティティ参照を使用したとの任意のメリット/注意点はありますか？、それが言うように、分類法は階層的な方法で同様のアイテムを整理するときに最もよく使用されます。タグのように。

分類法では、無料のタグ付け（コンテンツ分類法モジュールを使用して無効にすることができます）を使用できます。これにより、新しいタグをその場で作成できます。コンテンツのスケルトンを変更するのは非常に簡単です。このアプローチを使用すると、正規または少なくとも一部の認証されたユーザー（プログラミングの知識がない）がこのスケルトンを変更できます。階層選択モジュールは、そのようなアプローチの完璧な例です。

分類法は簡単に使用できますが、私自身はエンティティ参照を好みますが、多くの可能性とスケーラビリティが開かれ、非常に複雑な構造を作成できます。このコンテキストでのエンティティの概念はコンテンツに限定されません。コメント、ユーザー、分類法などです。これははるかにスケーラブルなので、コンテンツタイプのカスタマイズや将来の変更について心配する必要はありません（エンティティ参照と分類法で指摘されているように）。エンティティアプローチは分類法よりも強力だと思います。

これらのアプローチには、言及する必要のない他のいくつかの組み合わせもあります。

とにかく、エンティティのアプローチとそれに関連するモジュールを完全に理解することをお勧めします。複数のプロジェクトで使用する場合、その複雑さにもかかわらず、非常に簡単に使用できます。現在の要件だけでなく、将来的にも非常に信頼できるツールになります。

また、記事や問題がノード、雑誌が分類法であるノードなど、他の組み合わせも考えられます。

これに対する正解や誤解は実際にはありません。個人の好み、特定のプロジェクト要件などに起因します。

コンテンツにはノードを使用し、コンテンツの分類には分類法を使用するのが最適ですが、何かが単なる分類なのか、それ自体のコンテンツなのかについて、少し曖昧になることがあります。

たとえば、記事のタイプとキーワードのフィールドは、明らかに分類法のように見えますが、問題と雑誌は実際にはどちらの方法でもかまいません。

決定に影響を与える可能性のあるものの1つは、すぐに使える機能です。たとえば、タクソノミーの場合よりもノードのアドオンモジュールの方がはるかに多くありますが、タクソノミーの場合は（必要に応じて）ボックスリストのページから取得できます。また、1つのソリューションまたは他のソリューションを使用すると、すぐに利用できる階層関連の機能も存在する可能性があります。

コンテンツタイプの定義は、画像の一部にすぎません。コンテンツをユーザーに提示する方法、ユーザーがコンテンツの階層を移動する方法、このコンテンツがサイト上の他のコンテンツとどのように関連するか、管理者がこれを管理する方法を完全に検討する必要がありますコンテンツなど。たとえば、ある種の階層メニューシステムが必要ですか、雑誌や発行ページにアクセスできるようにしたいですか、それとも記事ページにのみ表示されるコンテンツに関連するコンテンツですか。3つのタイプのコンテンツすべてを一覧表示する単一の検索をしたいですか（一部がノードであり、一部が分類用語である場合、これはそれほど簡単ではない場合があります）。

これらすべてを計画し、それを実現するために利用できるモジュールを確認します。あなたはあなたが望むものを達成することをより簡単にする一つの方法を見つけるかもしれません。そうでない場合は、あなたが持っている理由にかかわらず、あなたが最善だと思うものを使用する必要があります。

場合によっては、一方向に進んで、要件の達成を困難にする何かを見つけることがあります。できる限り前もって計画しておけば、そのリスクを軽減できます。

「雑誌」などの分類用語を使用する際のもう1つの考慮事項は、それらのアイテムの改訂やコメントなどの機能を失うことです。許可されたリビジョンは、分類法リビジョンなどのモジュールで追加できますが、インストールベースが非常に低いモジュールです。個人的には、これを介してノードのリビジョン処理でコアを信頼します。

要件の変更によりプロジェクトが稼働した後に、分類用語からノードに何かを変更しなければならなかった少なくとも1つの場合を考えることができます。これには、かなりの再構築と移行が含まれます。

entity_referenceを使用したノードなど、他のエンティティタイプを使用することに移行した場合、すべてがほぼ同じように機能するため、変更を加える際に問題が発生することはありませんが、柔軟性が向上します。

これが最も正確な答えであるとは言いませんが、私がそれについて考える方法です。いくつか例を挙げて説明します。

私は通常、分類法を使用して、抽象化に基づいてノードを分類します。たとえば、ニュースはスポーツ、政治などに分類できます。

でも雑誌のように参考にしたいときは、未来を考えています。どの記事を選択するかをユーザーが決定できるようにしたい場合について考えます。雑誌ランク（おそらくインパクトファクター）は可能性があります。または、その雑誌に連絡したいのかもしれません。このような状況では用語は役に立ちません。ノードまたはエンティティの場合はそうです。

一方、自分でいくつかのことを行う必要があります。たとえば、分類用語をクリックすると、その用語の分類されたノードで満たされたページが表示されます。したがって、ビューとコンテキストフィルターなどが必要になります。

フィールドコレクションから離れる理由を尋ねられたのは確かですが、コメントは削除されたようです。どちらにせよ、私の2セント：

分類は分類と分類に使用する必要があります。コンテンツの関係ではありません。分類用語を介して2つのコンテンツをリンクすることにより、2つだけ必要な3つのエンティティを使用しています。

私の経験では、分類法は現在フィールド化可能ですが、完全な実体ではないため、「コンテンツ」として使用しないでください。

この特定のケースでは、雑誌にコンテンツ（内容の説明、注文の詳細など）、または独自の「ページ」がある場合、コンテンツであるため、コンテンツタイプである必要があります。

問題は少しあいまいですが、概要などがある可能性が高いため、おそらくページがあり、コンテンツでもあります。したがって、別のコンテンツタイプです。

記事は明らかにコンテンツタイプです。

このための管理者を構築する際に、エンティティリファレンスを使用してこれらのコンテンツをリンクできますが、もう1つ上手く行くことができます。

@Drupalistがフィールドコレクションの使用を提案したのと同じように、インラインエンティティフォームを使用できます（エンティティリファレンスの一部だと思います）。フィールドコレクションはこれらの古いモジュールの1つであり、優れたアイデアがあり、あまりうまく実装されておらず、他のモジュールとの衝突が多数あります。それらは現在エンティティーですが、まだ問題があり、作成者などのようなものには、完全なエンティティー（コンテンツ・タイプでさえも）を使用する方がよいでしょう。

インラインエンティティフォームを使用すると、参照元のエンティティ内から参照エンティティを作成および編集できます...したがって、記事内から作成者を作成/編集するか、既に作成されているものを参照するだけです。

CERを追加すると、著者から記事への参照、記事から問題への問題、問題への雑誌への参照、または今後の方向性が自動的に取得されます。これには、ビューの実行方法に利点がありますが、著者ページに記事のリストを表示し、記事ページに著者情報を表示できます。ビューはまったくありません。

分類法に戻ると、これらを使用して、記事に「釣り」、「車」、「コンピュータ」など/何でも「タグ付け」できます。そのため、問題、雑誌、記事を見つけることができますまたはそのタグについてコンテンツ/記述されている著者。

簡潔にしようとしたので、うまくいけばそれが助けになり、理にかなっています。私はこれを数十のサイトで行ってきました。グローバルなスポーツイベント、旅行/休日の予約サイト、国際放送局、飲料、チャリティーなど。強力で強力で、予期しない要件に対応します。