Ich frage mich, wie ich mich entscheiden soll, ob ich das Kernmodul Taxonomie oder das Entitätsreferenzmodul verwenden möchte .

Ich habe das Entitätsreferenzmodul zuvor nicht verwendet, aber ich habe das Taxonomiemodul (und einige verwandte Module) auf 10-15 Websites verwendet.

Was sind die Vor- oder Nachteile der Verwendung von referenzbasierten Modulen anstelle von Taxonomiemodulen?

Vor kurzem habe ich begonnen, eine Website für Zeitschriftenarchive zu erstellen.

Es gibt viele Zeitschriften. Diese Magazine haben Probleme. Jede Ausgabe enthält Artikel.

Der kleinste (und tiefste) Teil hier sind die Artikel .

Artikel

• Seitenzahl (Bereich):
• Titel:
• Autor:
• Artikeltyp:
• Schlüsselwörter:
• Zeitschrift:
• Problem:

Problem

• Ausgabe Nummer:
• Titelbild:
• Veröffentlichungsdatum):
• Zeitschrift:

Zeitschrift

• Beschreibung:
• Titelbild:

Hier gibt es (mindestens) 2 Methoden , um diese Website zu implementieren:

1. Es wird ein Inhaltstyp namens genannt, articleund alle anderen (Ausgabe, Magazin, Autor) sind taxonomische Begriffe (hierarchisch). Es würde eine Hierarchie zwischen Ausgabe und Zeitschrift usw. geben.

2. Es wird viele Inhaltstypen geben: Artikel, Ausgabe, Magazin, Autor. Beim Erstellen von Artikeln; Ausgabe, Zeitschrift und Autor können referenziert werden usw.

Theoretisch scheinen sich beide Wege also sehr ähnlich zu sein.

Gibt es jemanden, der mit einer ähnlichen Situation konfrontiert war, und können Sie bitte sagen, welche Methode Sie bevorzugt haben, warum?

Es gibt auch andere Lösungen für Ihr Problem.

Feldsammlung

Sie können mit Feld Sammlung und Feldauflistung Ansichten Module zu speichern und organisieren Inhalte. Mit diesem Ansatz des Issueund Magazinegeht Feldsammlungstyp sein, Issueist ein Feld Articleund Magazineist ein Feld Issue. Ich habe Erfahrung mit der Implementierung einer solchen Struktur. In meinem Fall bestand die Anforderung darin, Librarydass Bücher (mit den Feldern Titel, Herausgeber und ...) enthalten sein sollten. Jedes Buch enthält mehrere Bände (Anzahl der Seiten, Übersetzer, ...) und jeder Band enthält auch eine unbegrenzte Anzahl einiger anderer Elemente (wie das Scannen einiger Seiten, die in den Büchern nicht identisch sind).

Ich habe dies mit dem Field Collection-Ansatz implementiert und es ist sehr schön. Sie können einfach einen Link erstellen, um jedes einzelne Element jeder Feldsammlung zu bearbeiten, und Sie können auch nach Elementen der Feldsammlung filtern. Ich habe eine Antwort auf Gruppenelemente in Ansichten nach Wert in der Feldsammlung gepostet, die zeigt, wie mit Feldsammlungsansichten gearbeitet wird

Anhang zur Entitätsansicht

Auch als EVA- Modul bekannt.

"Eva" ist die Abkürzung für "Entity Views Attachment". Es bietet ein Plugin für die Anzeige von Ansichten, mit dem die Ausgabe einer Ansicht an den Inhalt einer beliebigen Drupal-Entität angehängt werden kann. Der Hauptteil eines Knotens oder Kommentars, das Profil eines Benutzerkontos oder die Auflistungsseite für einen Taxonomiebegriff sind Beispiele für Entitätsinhalte.

Sie können EVA verwenden, um nur Feldwerte für einen bestimmten Inhalt anzuzeigen, wodurch Sie eine unglaubliche Kontrolle über die Anzeige und Formatierungsflexibilität der Felder erhalten. Beispielsweise möchten Sie möglicherweise zwei Felder auf besondere Weise verketten lassen. Sie können Ihre Felder zu Ihrer EVA-Anzeige hinzufügen, den Kontextfilter auf NID setzen, ein globales: Textfeld hinzufügen und Ihre Felder mithilfe von Token mit HTML formatieren. Vergessen Sie nicht, Ihre Felder von der Anzeige auszuschließen, wenn Sie sie zusammen in einem Global: Text-Feld verwenden möchten. Beispiel: Möglicherweise haben Sie Stadt-, Bundesland- und Postleitzahlfelder. Sie können sie in einem globalen: Textfeld in Ansichten kombinieren, um sie als "Stadt, Bundesland Postleitzahl" anzuzeigen. Wenn Sie die Anzeige für Ihren Inhaltstyp verwalten, fügen Sie den soeben erstellten EVA zur Anzeige hinzu. Wenn ein Knoten des Typs angezeigt wird, übergibt er seine NID an den EVA und der EVA gibt die von Ihnen ausgewählten Felder zurück. formatiert nach Ihren Wünschen. (Quelle :Anwendungsfall für EVA- und Entitätsreferenzanleitungen )

Dieses Modul ist perfekt. Es fügt eine Ansicht als Feld an Knoten eines Inhaltstyps an. Ich habe dieses Modul verwendet, um eine zu erstellen Album. Das Album enthält singer(mit einigen Informationen zu jedem) und songsdas enthält eine Datei, einen Titel, eine Rate und .... Also habe ich eine Ansicht vom Typ EVA erstellt und sie an einen Knoten angehängt. Auf der Knotenseite jedes Sängers habe ich diese Ansicht angezeigt, die die entsprechenden Informationen vom Knoten erhält. Die Ansicht mit Entitätsreferenz ist ein perfektes Tutorial zur Verwendung dieses Moduls.

Taxonomiebegriffe VS Entitätsreferenz

Ich empfehle Ihnen zu lesen Entity Referenz vs. Taxonomie und Gibt es Vorteile / Einschränkungen bei der Verwendung von Entity - Referenz über Zeitreferenz? Wie es heißt, werden Taxonomien am besten verwendet, wenn ähnliche Elemente hierarchisch organisiert werden. Wie Tags .

Mit Taxonomy können Sie kostenloses Tagging verwenden (es kann mit dem Modul Content Taxonomy deaktiviert werden ), mit dem Sie im Handumdrehen neue Tags erstellen können . Es ist sehr einfach, das Skelett des Inhalts zu ändern. Mit diesem Ansatz können reguläre oder zumindest einige authentifizierte Benutzer (die keine Programmierkenntnisse haben) dieses Skelett ändern. Hierarchische Select Modul ist perfektes Beispiel für eine solche Vorgehensweise.

Obwohl Taxonomie einfach zu verwenden ist, ich selbst die Entitätsreferenz bevorzuge, eröffnet sie viele Möglichkeiten und Skalierbarkeit und ermöglicht die Erstellung sehr komplexer Strukturen. Das Konzept der Entität ist in diesem Zusammenhang nicht auf den Inhalt beschränkt. Es können Kommentare, Benutzer, Taxonomien und .... sein. Es ist viel skalierbarer, sodass Sie sich keine Gedanken über das Anpassen oder Ändern von Inhaltstypen in der Zukunft machen müssen (wie in Entitätsreferenz vs. Taxonomie ausgeführt ). Ich glaube, der Entity-Ansatz ist leistungsfähiger als die Taxonomie.

Es gibt auch einige andere Kombinationen dieser Ansätze, die nicht erwähnt werden müssen.

Auf jeden Fall empfehle ich Ihnen, den Entity-Ansatz und die zugehörigen Module vollständig zu verstehen. Wenn Sie es in mehreren Projekten verwenden, ist es trotz seiner Komplexität sehr einfach für Sie, es zu verwenden. Nicht nur in Ihrer aktuellen Anforderung, sondern auch in Zukunft wird es ein sehr zuverlässiges Werkzeug für Sie sein.

Sie können auch eine andere Kombination verwenden, z. B. Artikel und Ausgaben sind Knoten und Zeitschriften sind Taxonomien.

Es gibt keine richtige oder falsche Antwort darauf, es kommt auf persönliche Vorlieben, spezifische Projektanforderungen usw. an.

Es ist am besten, Knoten für Inhalte und Taxonomien für die Kategorisierung dieses Inhalts zu verwenden. Manchmal kann es jedoch etwas trübe werden, ob es sich bei etwas nur um Kategorisierung oder um eigenen Inhalt handelt.

Zum Beispiel scheinen Ihre Artikeltyp- und Schlüsselwortfelder offensichtlicher Taxonomien zu sein, aber Ausgabe und Zeitschriften könnten wirklich in beide Richtungen gehen.

Eine Sache, die Ihre Entscheidung beeinflussen könnte, ist die sofort einsatzbereite Funktionalität. Zum Beispiel gibt es viel mehr Zusatzmodule für Knoten als für Taxonomien, aber für Taxonomien erhalten Sie sofort Listen mit Seiten (falls gewünscht). Möglicherweise gibt es auch hierarchiebezogene Funktionen, die mit der einen oder anderen Lösung leichter sofort einsatzbereit sind.

Inhaltstypdefinitionen sind nur ein Teil des Bildes. Sie sollten auf jeden Fall genau überlegen, wie der Inhalt dem Benutzer präsentiert werden soll, wie der Benutzer durch die Hierarchie der Inhalte navigieren soll, in welcher Beziehung dieser Inhalt zu anderen Inhalten auf der Website steht und wie Administratoren dies verwalten sollen Inhalt usw. Möchten Sie beispielsweise eine Art hierarchisches Menüsystem, möchten Sie, dass Personen zu Zeitschriften- oder Ausgabeseiten gehen können, oder beziehen sich Inhalte auf diejenigen, die nur auf den Artikelseiten sichtbar sind. Möchten Sie eine einzige Suche durchführen, in der alle drei Arten von Inhalten aufgelistet sind (dies ist möglicherweise weniger trivial, wenn einige Knoten und andere taxonomische Begriffe sind).

Planen Sie das alles und sehen Sie dann, welche Module verfügbar sind, um dies zu erreichen. Möglicherweise finden Sie einen Weg, der es einfacher macht, das zu erreichen, was Sie wollen. Wenn nicht, müssen Sie sich einfach für die entscheiden, die Sie aus welchen Gründen auch immer für am besten halten.

Manchmal gehen Sie einen Weg und finden dann etwas, das es schwierig macht, Ihre Anforderungen zu erfüllen. Wenn Sie es so weit wie möglich im Voraus planen, verringern Sie dieses Risiko.

Eine weitere Überlegung bei der Verwendung von Taxonomiebegriffen für Dinge wie "Magazin" ist, dass Sie Funktionen wie Überarbeitungen und Kommentare zu diesen Elementen verlieren. Zugegebene Revisionen können mit einem Modul wie Taxonomy Revision hinzugefügt werden , dies ist jedoch ein Modul mit einer sehr geringen Installationsbasis. Persönlich würde ich darauf vertrauen, dass Core über das Revisionshandling auf Knoten verfügt.

Ich kann mir mindestens eine Gelegenheit vorstellen, bei der ich etwas von einem Taxonomiebegriff in einen Knoten ändern musste, nachdem ein Projekt aufgrund geänderter Anforderungen in Betrieb genommen wurde, und dies erfordert einiges an Umstrukturierung und Migration.

Wenn Sie andere Entitätstypen wie Knoten mit entity_reference verwenden, werden Sie wahrscheinlich keine Probleme haben, die Änderung vorzunehmen, da alles auf die gleiche Weise funktioniert, Sie jedoch mehr Flexibilität erhalten.

Ich werde nicht sagen, dass dies die genaueste Antwort ist, aber so denke ich darüber. Ich werde mit einigen Beispielen erklären.

Normalerweise verwende ich Taxonomien, um Knoten basierend auf einer Abstraktion zu kategorisieren. Zum Beispiel können Nachrichten in Sport, Politik usw. eingeteilt werden.

Aber wenn ich eine Referenz wie eine Zeitschrift haben möchte, denke ich an die Zukunft. Überlegen Sie, wann Sie dem Benutzer bei der Entscheidung helfen möchten, welchen Artikel er auswählen soll. Der Magazinrang (Impact Factor vielleicht) ist eine Möglichkeit. Oder vielleicht möchte ich diese Zeitschrift kontaktieren. Ein Begriff würde mir in dieser Situation nicht helfen, wenn es sich um einen Knoten oder eine Entität handeln würde.

Auf der anderen Seite musst du ein paar Sachen selbst machen. Wenn Sie beispielsweise auf einen Taxonomiebegriff klicken, gelangen Sie zu einer Seite, die mit kategorisierten Knoten dieses Begriffs gefüllt ist. Nun wird eine Ansicht und ein Kontextfilter usw. benötigt.

Ich war mir sicher, dass jemand gefragt hat, warum ich mich von Feldsammlungen fernhalten würde, aber der Kommentar scheint entfernt worden zu sein. So oder so meine 2 Cent:

Taxonomien sollten zur Klassifizierung und Kategorisierung verwendet werden. Nicht für Inhaltsbeziehungen. Durch Verknüpfen von 2 Inhalten über einen Taxonomiebegriff verwenden Sie 3 Entitäten, für die Sie nur 2 benötigen.

Nach meiner Erfahrung sind Taxonomien zwar jetzt feldfähig, aber keine vollwertigen Einheiten und sollten daher nicht als "Inhalt" verwendet werden.

In diesem speziellen Fall sollte es sich bei Ihrem Magazin um einen Inhaltstyp handeln, wenn es Inhalt enthält (eine Beschreibung dessen, was es ist, Einzelheiten zur Bestellung usw.) oder eine eigene "Seite".

Die Probleme sind etwas mehrdeutig, aber wahrscheinlich haben Sie einen Überblick usw., sodass sie wahrscheinlich eine Seite haben und wahrscheinlich auch Inhalt haben. Also ein anderer Inhaltstyp.

Die Artikel sind offensichtlich Inhaltstypen.

Wenn Sie den Administrator dafür erstellen, können Sie diese Inhalte mithilfe der Entitätsreferenz verknüpfen, aber Sie können noch einen Schritt weiter gehen.

Auf die gleiche Weise, wie @Drupalist die Verwendung von Feldsammlungen vorgeschlagen hat, können Sie Inline-Entitätsformulare verwenden (ich denke, Teil der Entitätsreferenz). Feldsammlungen sind eines dieser alten Module, die eine großartige Idee waren, nicht sehr gut umgesetzt wurden und viele Kollisionen mit anderen Modulen aufwiesen. Obwohl sie jetzt Entitäten sind, haben sie immer noch Probleme, und Sie sollten besser vollwertige Entitäten (sogar Inhaltstypen) für Dinge wie Ihre Autoren usw. verwenden.

Mit Inline-Entitätsformularen können Sie referenzierte Entitäten innerhalb der Entität erstellen und bearbeiten, auf die Sie verweisen möchten. Erstellen / bearbeiten Sie also den Autor innerhalb eines Artikels oder verweisen Sie einfach auf eine bereits erstellte Entität.

Wenn Sie CER hinzufügen, erhalten Sie vom Autor automatisch einen Verweis zurück zum Artikel, den Artikel zurück zur Ausgabe und die Ausgabe zurück zum Magazin oder in eine andere Richtung. Dies hat Vorteile für die Leistung Ihrer Ansichten, ermöglicht Ihnen jedoch auch die Anzeige einer Liste von Artikeln auf der Autorenseite und der Autoreninformationen auf der Artikelseite, alle ohne Ansichten.

Wenn Sie den Kreis zurück zu den Taxonomien schließen, können Sie diese verwenden, um Artikel usw. mit ... "Angeln", "Auto", "Computer" usw. / was auch immer zu "markieren", damit Sie jede Ausgabe, Zeitschrift oder jeden Artikel finden können oder Autor, der Inhalt / über dieses Tag geschrieben hat.

Ich habe versucht, mich kurz zu fassen, also hilft es hoffentlich und macht Sinn. Ich habe dies auf Dutzenden von Websites getan. Globale Sportveranstaltungen, Websites für Reise- / Urlaubsbuchungen, internationale Sender, Getränke, Wohltätigkeitsorganisationen usw. Robust, leistungsstark und für unvorhergesehene Anforderungen.