分類法モジュールの代わりに参照ベースのモジュールを使用する利点と欠点は何ですか？
コア分類法モジュールまたは エンティティ参照 モジュールのどちらを使用するかを決定する方法を知りたいですか？
以前はエンティティ参照モジュールを使用していませんでしたが、10〜15のWebサイトで分類法モジュール（およびいくつかの関連モジュール）を使用しました。
分類法モジュールの代わりに参照ベースのモジュールを使用する利点と欠点は何ですか？
最近、雑誌のアーカイブサイトを作り始めました。
雑誌はたくさんあります。これらの雑誌には問題があります。各号には記事があります。
ここで最も小さい（そして最も深い）部分はarticlesです。
論文
- ページ番号（範囲）：
- 題名：
- 著者：
- 記事タイプ：
- キーワード：
- 雑誌：
- 問題：
問題
- 発行番号：
- 表紙画像：
- 日付（公開）：
- 雑誌：
マガジン
- 説明：
- 表紙画像：
ここでは、（少なくとも）2つのメソッドがこのWebサイトを実装します。
1。articleというコンテンツタイプがあり、その他すべて（問題、雑誌、著者）は分類用語（階層）です。発行と雑誌などの間に階層があります。
2。多くのコンテンツタイプがあります：記事、問題、雑誌、著者。記事を作成しながら;号、雑誌、著者などを参考にすることができます。
したがって、理論的には両方の方法が非常に似ているように見えます。
同様の状況に直面した人はいませんか。どの方法をお勧めしたのですか、なぜですか。
問題に対する他の解決策もあります。
フィールドコレクション
フィールドコレクション および フィールドコレクションビュー モジュールを使用して、コンテンツを保存および整理できます。このアプローチを使用すると、IssueとMagazineはフィールドコレクションタイプになり、IssueはArticleのフィールドであり、MagazineはIssueのフィールド。私はそのような構造を実装した経験があります。私の場合、要件はLibraryであり、書籍（タイトル、出版社、および...フィールドを含む）を含む必要があり、すべての書籍には複数のボリューム（ページ数、翻訳者、...）が含まれ、各ボリュームにも含まれていますその他のアイテムの数に制限はありません（書籍間で異なる一部のページのスキャンなど）。
私はフィールドコレクションアプローチを使用してこれを実装しました。すべてのフィールドコレクションの個々のアイテムを編集するためのリンクを簡単に作成でき、フィールドコレクションのアイテムでフィルタリングすることもできます。フィールドコレクションビューでの作業方法を示す フィールドコレクションの値でビューのアイテムをグループ化 への回答を投稿しました
エンティティビューの添付ファイル
[〜＃〜] eva [〜＃〜] モジュールとも呼ばれます。
「Eva」は「Entity Views Attachment」の略です。ビューの出力を任意のDrupalエンティティのコンテンツに添付できるようにするビュー表示プラグインを提供します。ノードまたはコメントの本文、ユーザーアカウントのプロファイル、または分類用語のリストページは、すべてエンティティコンテンツの例です。
EVAを使用して特定のコンテンツのフィールド値のみを表示し、フィールドの表示とフォーマットの柔軟性を驚くほど制御できます。たとえば、特別な方法で2つのフィールドを連結したい場合があります。フィールドをEVAディスプレイに追加し、コンテキストフィルターをNIDに設定し、グローバル：テキストフィールドを追加し、トークンを使用してフィールドをHTMLでフォーマットできます。グローバル：テキストフィールドでフィールドを一緒に使用する場合は、フィールドを表示から除外することを忘れないでください。例：都市、州、郵便番号のフィールドがあるとします。これらをビューのグローバル：テキストフィールドで組み合わせて、「市、州の郵便番号」として表示できます。コンテンツタイプの表示を管理する場合は、作成したばかりのEVAを表示に追加します。タイプが表示されるノードは常にそのnidをEVAに渡し、EVAは選択したフィールドを希望どおりにフォーマットして返します。 （ソース： EVAおよびエンティティリファレンスの使用例 ）
このモジュールは完璧です。コンテンツタイプのノードにフィールドとしてビューをアタッチします。このモジュールを使用してAlbumを作成しました。アルバムにはsinger（それぞれについてのいくつかの情報を含む）とsongsが含まれ、ファイル、タイトル、レートなどが含まれます。そこで、タイプ[〜＃〜] eva [〜＃〜]のビューを作成し、それをノードにアタッチしました。したがって、すべてのSingerのノードページに、ノードから適切な情報を取得するこのビューを表示しました。 エンティティ参照付きのビュー は、このモジュールの使用方法の完全なチュートリアルです。
分類用語V.Sエンティティリファレンス
エンティティ参照と分類法 および 用語参照よりもエンティティ参照を使用することには利点/注意点がありますか？ を読むことをお勧めします分類法は、類似したアイテムを階層的に整理する場合に最適です。タグのように。
分類法では、無料のタグ付けを使用できます（Content Taxonomyモジュールを使用して無効化できます）。これにより、新しいタグをその場で作成できます。コンテンツのスケルトンを変更するのは非常に簡単です。このアプローチを使用すると、正規または少なくとも一部の認証されたユーザー（プログラミングの知識がない）がこのスケルトンを変更できます。 階層選択 モジュールは、そのようなアプローチの完璧な例です。
分類法は簡単に使用できますが、私自身はエンティティ参照を好みますが、多くの可能性とスケーラビリティが開かれ、非常に複雑な構造を作成できます。このコンテキストでのエンティティの概念はコンテンツに限定されません。コメント、ユーザー、分類法などです。はるかにスケーラブルなので、コンテンツタイプのカスタマイズや将来の変更について心配する必要はありません（エンティティ参照と分類法で指摘されているように）。エンティティアプローチは分類法よりも強力だと思います。
これらのアプローチには、言及する必要のない他のいくつかの組み合わせもあります。
とにかく、エンティティのアプローチとそれに関連するモジュールを完全に理解することをお勧めします。複数のプロジェクトで使用する場合、その複雑さにもかかわらず、非常に簡単に使用できます。現在の要件だけでなく、将来的にも、非常に信頼性の高いツールになるでしょう。
また、記事や問題がノード、雑誌が分類法であるノードなど、他の組み合わせも考えられます。
これに対する正解や誤解は実際にはありません。個人の好み、特定のプロジェクト要件などに起因します。
コンテンツにはノードを使用し、コンテンツの分類には分類法を使用するのが最適ですが、何かが単なる分類なのか、それ自体のコンテンツなのかについて、少し曖昧になることがあります。
たとえば、記事のタイプとキーワードのフィールドは、明らかに分類法のように見えますが、問題と雑誌は実際にはどちらの方法でもかまいません。
決定に影響を与える可能性のあるものの1つは、すぐに使用できる機能です。たとえば、タクソノミーの場合よりもノードのアドオンモジュールの方がはるかに多くありますが、タクソノミーの場合は（必要に応じて）ボックスリストのページから取得できます。また、1つのソリューションまたは他のソリューションを使用すると、すぐに利用できる階層関連の機能も存在する可能性があります。
コンテンツタイプの定義は、画像の一部にすぎません。コンテンツをユーザーに提示する方法、ユーザーがコンテンツの階層を移動する方法、このコンテンツがサイト上の他のコンテンツとどのように関連するか、管理者がこれを管理する方法を完全に考慮する必要がありますコンテンツなど。たとえば、ある種の階層メニューシステムが必要なのか、人々が雑誌や発行ページにアクセスできるようにしたいのか、それとも記事ページにのみ表示されるコンテンツに関連したコンテンツなのか。 3つのタイプのコンテンツすべてを一覧表示する単一の検索をしたいですか（一部がノードであり、一部が分類用語である場合、これはそれほど簡単ではない場合があります）。
これらすべてを計画し、それを実現するために利用できるモジュールを確認します。あなたはあなたが望むものを達成することをより簡単にする一つの方法を見つけるかもしれません。そうでなければ、あなたはあなたが持っているどんな理由でもあなたが最良だと思うものと一緒に行かなければなりません。
場合によっては、一方向に進んで、要件の達成を困難にする何かを見つけることがあります。できる限り前もって計画しておけば、そのリスクを軽減できます。
「雑誌」などの分類用語を使用する際のもう1つの考慮事項は、それらのアイテムの改訂やコメントなどの機能を失うことです。許可されたリビジョンは Taxonomy revision などのモジュールで追加できますが、これはインストールベースが非常に低いモジュールです。個人的には、これを介してノードのリビジョン処理でコアを信頼します。
要件の変更によりプロジェクトが稼働した後に、分類用語からノードに何かを変更しなければならなかった少なくとも1つの場合を考えることができます。これには、かなりの再構築と移行が含まれます。
Entity_referenceを使用したノードなど、他のエンティティタイプを使用することに移行した場合、すべてがほぼ同じように機能するため、変更を加える際に問題が発生することはありませんが、柔軟性が向上します。
これが最も正確な答えであるとは言いませんが、私がそれについて考える方法です。いくつか例を挙げて説明します。
私は通常、分類法を使用して、抽象化に基づいてノードを分類します。たとえば、ニュースはスポーツ、政治などに分類できます。
でも雑誌のように参考にしたいときは、未来を考えています。どの記事を選択するかをユーザーが決定できるようにしたい場合について考えます。雑誌ランク（おそらくインパクトファクター）は可能性があります。または、その雑誌に連絡したいのかもしれません。このような状況では用語は役に立ちません。ノードまたはエンティティの場合はそうです。
一方、自分でいくつかのことを行う必要があります。たとえば、分類用語をクリックすると、その用語の分類されたノードで満たされたページが表示されます。したがって、ビューとコンテキストフィルターなどが必要になります。
フィールドコレクションから離れる理由を尋ねられたのは確かですが、コメントは削除されたようです。どちらにせよ、私の2セント：
分類は分類と分類に使用する必要があります。コンテンツの関係ではありません。分類用語を介して2つのコンテンツをリンクすることにより、2つだけ必要な3つのエンティティを使用しています。
私の経験では、分類法は現在フィールド化可能ですが、完全な実体ではないため、「コンテンツ」として使用しないでください。
この特定のケースでは、雑誌にコンテンツ（内容の説明、注文の詳細など）、または独自の「ページ」がある場合、コンテンツであるため、コンテンツタイプである必要があります。
問題は少しあいまいですが、概要などがある可能性が高いため、おそらくページがあり、コンテンツでもあります。したがって、別のコンテンツタイプです。
記事は明らかにコンテンツタイプです。
このための管理者を構築する際に、エンティティリファレンスを使用してこれらのコンテンツをリンクできますが、もう1つ上手く行くことができます。
@Drupalistがフィールドコレクションの使用を提案したのと同じように、インラインエンティティフォームを使用できます（エンティティリファレンスの一部だと思います）。フィールドコレクションはこれらの古いモジュールの1つであり、優れたアイデアがあり、あまりうまく実装されておらず、他のモジュールとの衝突が多数あります。それらは現在エンティティーですが、まだ問題があり、作成者などのようなものには、完全なエンティティー（コンテンツ・タイプでさえも）を使用する方がよいでしょう。
インラインエンティティフォームを使用すると、参照元のエンティティ内から参照エンティティを作成および編集できます...したがって、記事内から作成者を作成/編集するか、既に作成されているものを参照するだけです。
CERを追加すると、著者から記事への参照、記事から号への返答、号から雑誌への参照、または今後の方向性が自動的に取得されます。これは、ビューの実行方法に利点がありますが、著者ページに記事のリストを表示し、記事ページに著者情報を表示することもできます。ビューはまったくありません。
分類法に戻ると、これらを使用して、記事に「釣り」、「車」、「コンピュータ」など/何でも「タグ付け」できます。そのため、問題、雑誌、記事を見つけることができますまたはそのタグについてコンテンツ/記述されている著者。
簡潔にしようとしたので、うまくいけばそれが助けになり、理にかなっています。私はこれを数十のサイトで行ってきました。グローバルなスポーツイベント、旅行/休日の予約サイト、国際放送局、飲料、チャリティーなど。強力で強力で、予期しない要件に対応します。