Quels sont les avantages ou les inconvénients de l'utilisation de modules basés sur des références au lieu du module de taxonomie?
Je me demande comment décider d'utiliser le module de taxonomie de base ou le module Entity Reference ?
Je n'ai pas utilisé le module Entity Reference auparavant, mais j'ai utilisé le module de taxonomie (et certains modules connexes) sur 10 à 15 sites Web.
Quels sont les avantages ou les inconvénients d'utiliser des modules basés sur des références au lieu du module de taxonomie?
Récemment, j'ai commencé à créer un site Web d'archives de magazines.
Il y a beaucoup de magazines. Ces magazines ont des problèmes. Chaque numéro contient des articles.
La partie la plus petite (et la plus profonde) est ici les articles .
Article
- Numéro de page (plage):
- Titre:
- Auteur:
- Type d'article:
- Mots clés:
- Magazine:
- Problème:
Problème
- Numéro de série:
- Image de couverture:
- Date publiée):
- Magazine:
Magazine
- La description:
- Image de couverture:
Ici, il existe (au moins) 2 méthodes pour implémenter ce site:
1. Il y aura un type de contenu appelé article et tous les autres (numéro, magazine, auteur) seront des termes de taxonomie (hiérarchique) . Il y aurait une hiérarchie entre le numéro et le magazine, etc.
2. Il y aura beaucoup de types de contenu: article, numéro, magazine, auteur. Lors de la création d'articles; le numéro, le magazine et l'auteur peuvent être référencés, etc.
Donc, théoriquement, les deux façons semblent très similaires.
Y a-t-il quelqu'un qui a fait face à une situation similaire et pourriez-vous s'il vous plaît dire quelle méthode vous avez préférée, pourquoi?
Il existe également d'autres solutions à votre problème.
Collecte sur le terrain
Vous pouvez utiliser les modules collection de champs et vues de collection de champs pour stocker et organiser le contenu. En utilisant cette approche, les Issue et Magazine vont être de type Collection de champs, Issue est un champ de Article et Magazine est un champ de Issue. J'ai l'expérience de la mise en œuvre d'une telle structure. Dans mon cas, l'exigence était un Library qui devrait contenir des livres (avec les champs Title, Publisher et ...), Chaque livre contient plusieurs volumes (Nombre de pages, traducteur, ...) et chaque volume contient également nombre illimité d'autres éléments (comme la numérisation de certaines pages qui ne sont pas les mêmes parmi les livres).
J'ai implémenté cela en utilisant l'approche Field Collection et c'est très agréable. Vous pouvez facilement créer un lien pour modifier chaque élément individuel de chaque collection de champs et vous pouvez également filtrer par éléments de la collection de champs. J'ai posté une réponse à Grouper les éléments dans les vues par valeur dans la collection de champs qui montre comment travailler avec les vues de collection de champs
Pièce jointe de vue d'entité
Également connu sous le nom de module EVA .
"Eva" est l'abréviation de "Entity Views Attachment;" il fournit un plugin d'affichage de vues qui permet d'attacher la sortie d'une vue au contenu de n'importe quelle entité Drupal. Le corps d'un nœud ou d'un commentaire, le profil d'un compte d'utilisateur ou le La page de liste d'un terme de taxonomie sont tous des exemples de contenu d'entité.
Vous pouvez utiliser EVA pour afficher uniquement les valeurs des champs pour un élément de contenu particulier, donnant un contrôle incroyable sur la flexibilité d'affichage et de formatage des champs. Par exemple, vous pouvez souhaiter que deux champs soient concaténés d'une manière spéciale. Vous pouvez ajouter vos champs à votre affichage EVA, définir le filtre contextuel sur NID, ajouter un champ de texte global: et utiliser des jetons pour formater vos champs avec HTML. N'oubliez pas d'exclure vos champs de l'affichage si vous comptez les utiliser ensemble dans un champ global: texte. Exemple: vous pouvez avoir une ville, un état et des champs Zip. Vous pouvez les combiner dans un champ de texte global: dans les vues pour les afficher comme "ville, code postal". Lorsque vous gérez l'affichage pour votre type de contenu, ajoutez l'EVA qui vient d'être créé à l'affichage et chaque fois qu'un nœud du type est affiché, il transmettra son nid à l'EVA et l'EVA retournera les champs que vous sélectionnez, formatés comme vous le souhaitez. (source: EVA et Entity Reference Use Case How-to )
Ce module est parfait, il attache une vue en tant que champ à des nœuds d'un type de contenu. J'ai utilisé ce module pour créer un Album. L'album contient singer (avec quelques informations sur chacun) et songs qui contient un fichier, un titre, un taux et .... J'ai donc créé une vue de type [~ # ~] eva [~ # ~] et je l'ai attachée à un nœud. Donc, sur la page du nœud de chaque chanteur, j'ai affiché cette vue qui obtient les informations appropriées du nœud. Vues avec référence d'entité est un tutoriel parfait sur la façon d'utiliser ce module.
Termes taxonomiques V.S Entity Reference
Je vous recommande de lire Référence d'entité contre taxonomie et Y a-t-il des avantages/mises en garde à utiliser la référence d'entité sur la référence de terme? , comme il est dit Les taxonomies sont les meilleures utilisé lors de l'organisation d'articles similaires de manière hiérarchique. Comme les balises.
La taxonomie vous permet d'utiliser le balisage gratuit (il peut être désactivé à l'aide du module Taxonomie du contenu ), ce qui permet la création de nouvelles balises à la volée. Il est très facile de modifier le squelette du contenu. En utilisant cette approche, des utilisateurs réguliers ou au moins certains utilisateurs authentifiés (qui n'ont aucune connaissance de la programmation) peuvent changer ce squelette. Hierarchical Select module est un exemple parfait d'une telle approche.
Même si la taxonomie est facile à utiliser mais je préfère moi-même Entity Reference, elle ouvre beaucoup de possibilités et d'évolutivité et permet de créer des structures très complexes. Le concept d'entité dans ce contexte ne se limite pas au contenu. Il peut s'agir de commentaires, d'utilisateurs, de taxonomies et .... Il est beaucoup plus évolutif, vous n'aurez donc pas à vous soucier de la personnalisation des types de contenu ou de leur modification à l'avenir (comme cela a été souligné dans Référence d'entité vs taxonomie). Je pense que l'approche Entité est plus puissante que la taxonomie.
Il existe également d'autres combinaisons de ces approches qu'il n'est pas nécessaire de mentionner.
Quoi qu'il en soit, je vous recommande de bien comprendre l'approche Entity et ses modules associés. Si vous l'utilisez dans plusieurs projets, malgré sa complexité, il vous sera très facile de l'utiliser. Non seulement dans vos besoins actuels, mais aussi à l'avenir, cela sera un outil très fiable pour vous.
Vous pouvez également avoir une autre combinaison, comme les articles et les numéros sont des nœuds et les magazines sont des taxonomies.
Il n'y a pas vraiment de bonne ou de mauvaise réponse pour cela, cela dépend des préférences personnelles, des exigences spécifiques du projet, etc.
Il est préférable d'utiliser des nœuds pour le contenu et des taxonomies pour la catégorisation de ce contenu, mais parfois il peut être un peu trouble de savoir si quelque chose n'est qu'une catégorisation ou son propre contenu.
Par exemple, vos champs de type d'article et de mots clés sembleraient plus évidemment être des taxonomies, mais les numéros et les magazines pourraient vraiment aller dans les deux sens.
Une chose qui pourrait influencer votre décision est la fonctionnalité prête à l'emploi. Par exemple, il y a beaucoup plus de modules complémentaires pour les nœuds que pour les taxonomies, mais pour les taxonomies, vous sortez des pages de liste de boîte (si vous les voulez). Il peut également y avoir des fonctionnalités liées à la hiérarchie qui sont plus faciles à sortir de la boîte avec une solution ou l'autre.
Les définitions de type de contenu ne sont qu'une partie de l'image. Vous devez absolument réfléchir à la façon dont vous souhaitez que le contenu soit présenté à l'utilisateur, comment vous souhaitez que l'utilisateur navigue dans la hiérarchie du contenu, comment ce contenu est-il lié aux autres contenus du site, comment voulez-vous que les administrateurs administrent cela contenu, etc. Par exemple, voulez-vous une sorte de système de menu hiérarchique, voulez-vous que les gens puissent aller au magazine ou publier des pages ou que le contenu lié à ceux-ci ne soit visible que sur les pages de l'article. Voulez-vous avoir une recherche unique qui répertorie les 3 types de contenu (cela peut être moins trivial si certains sont des nœuds et d'autres sont des termes de taxonomie).
Planifiez tout cela et voyez quels modules sont disponibles pour vous aider à y parvenir. Vous trouverez peut-être une façon de réaliser plus facilement ce que vous voulez. Si ce n'est pas le cas, il vous suffit de choisir celui que vous jugez le mieux pour toutes les raisons que vous avez.
Parfois, vous pouvez aller dans un sens et trouver quelque chose qui rend difficile la réalisation de vos exigences. Si vous le planifiez à l'avance autant que possible, vous réduisez ce risque.
Une autre considération lorsque vous utilisez des termes de taxonomie pour des choses comme "Magazine" est que vous perdrez des fonctionnalités telles que la révision et les commentaires sur ces éléments. Les révisions accordées peuvent être ajoutées avec un module tel que révision de la taxonomie mais c'est un module avec une base d'installation très faible. Personnellement, je ferais confiance à Core's sur la gestion des révisions sur les nœuds.
Je peux penser à au moins une occasion où j'ai dû changer quelque chose d'un terme de taxonomie à un nœud après qu'un projet soit devenu opérationnel en raison de changements dans les exigences, et cela implique un peu de restructuration et de migration.
Vous constaterez probablement que si vous passez à l'utilisation d'autres types d'entités tels que les nœuds avec entity_reference, vous n'aurez aucun problème à effectuer la modification, car tout fonctionne de la même manière, mais cela vous donnera plus de flexibilité.
Je ne dirai pas que c'est la réponse la plus précise, mais c'est la façon dont j'y pense. J'expliquerai avec quelques exemples.
J'utilise généralement des taxonomies pour classer les nœuds en fonction d'une abstraction. Par exemple, les informations peuvent être classées en sport, politique, etc.
Mais quand je veux avoir une référence comme un magazine, je pense à l'avenir. Réfléchissez quand vous voulez aider l'utilisateur à décider quel article choisir. Le classement du magazine (Impact Factor peut-être) est une possibilité. Ou peut-être que je veux contacter ce magazine. Un terme ne m'aiderait pas dans cette situation, où s'il s'agissait d'un nœud ou d'une entité, il le serait.
D'un autre côté, vous devez faire certaines choses par vous-même. Par exemple, cliquer sur un terme de taxonomie vous mènerait à une page remplie de nœuds classés de ce terme. Alors maintenant, une vue et un filtre contextuel sont nécessaires, etc.
J'étais sûr que quelqu'un avait demandé pourquoi je resterais à l'écart des collections sur le terrain, mais le commentaire semble avoir été supprimé. De toute façon mes 2 cents:
Des taxonomies devraient être utilisées pour la classification et la catégorisation. Pas pour les relations de contenu. En reliant 2 éléments de contenu via un terme de taxonomie, vous utilisez 3 entités dont vous n'avez besoin que de 2.
D'après mon expérience, bien que les taxonomies soient désormais utilisables sur le terrain, elles ne sont pas des entités à part entière et ne devraient donc pas être utilisées comme "contenu".
Dans ce cas particulier, si votre magazine contient du contenu (une description de ce que c'est, des détails sur sa commande, etc.), ou une "page" qui lui est propre, alors il doit s'agir d'un type de contenu, car c'est du contenu.
Les problèmes sont un peu ambigus, mais il y a de fortes chances que vous ayez un aperçu, etc., donc ils ont probablement une page et sont probablement du contenu aussi. Donc, un autre type de contenu.
Les articles sont évidemment des types de contenu.
En créant l'administrateur pour cela, vous pouvez utiliser la référence d'entité pour lier ces éléments de contenu, mais vous pouvez aller mieux.
De la même manière que @Drupalist a suggéré d'utiliser les collections de champs, vous pouvez utiliser des formulaires d'entité en ligne (je pense qu'une partie de la référence d'entité). Les collections de champs sont l'un de ces anciens modules qui étaient une excellente idée, pas très bien implémentée, et avec de nombreuses collisions avec d'autres modules. Bien qu'ils soient maintenant des entités, ils ont toujours des problèmes, et vous feriez mieux d'utiliser des entités à part entière (même des types de contenu) pour des choses comme vous, les auteurs, etc.
Les formulaires d'entité en ligne vous permettent de créer et de modifier des entités référencées, depuis l'intérieur de l'entité à partir de laquelle vous souhaitez référencer ... donc, de créer/modifier un auteur à partir d'un article, ou simplement de référencer un qui a déjà été créé.
Ajoutez CER et vous obtiendrez automatiquement une référence de l'auteur à l'article, à l'article au numéro et au numéro dans le Magazine, ou quelle que soit la direction dans laquelle vous allez. Cela présente des avantages dans la façon dont vos vues fonctionnent, mais vous permet également d'afficher une liste d'articles sur la page de l'auteur et les informations sur l'auteur sur la page de l'article, le tout sans aucune vue.
Faites un tour complet vers les taxonomies, vous les utiliseriez alors pour "taguer" des articles, etc. avec ... "pêche", "voiture", "ordinateurs", etc./quoi que ce soit ... pour que vous puissiez trouver n'importe quel numéro, magazine, article ou auteur qui a du contenu/écrit sur cette balise.
J'ai essayé d'être bref, donc j'espère que cela aide et a du sens. Je l'ai fait sur des dizaines de sites. Événements sportifs mondiaux, sites de réservation de voyages/vacances, radiodiffuseurs internationaux, boissons, œuvres de bienfaisance, etc. Puissant et robuste, et vous couvre pour les besoins imprévus.