Référence d'entité vs taxonomie


10

Disons que j'ai une équipe, qui a des membres. J'ai un type de contenu pour l'équipe et un type de contenu pour les membres individuels de l'équipe. Disons qu'il y a aussi d'autres relations, par exemple les équipes peuvent appartenir à des départements, et il y a des projets qui peuvent être assignés à des individus ou des équipes.

Si je comprends bien, il y a deux façons de définir les relations entre ces entités - soit des références d'entité, soit des termes de taxonomie. Quand devrais-je utiliser un type plutôt qu'un autre? Est-il préférable de choisir une seule méthode ou de les mélanger?

Il me semble que la taxonomie est la plus flexible, car il est facile de construire des arbres en utilisant des types de taxonomie, ou par exemple si au sein d'une équipe, j'ai alors décidé de créer une hiérarchie dans l'équipe, la fonctionnalité est déjà là (faites simplement glisser le termes de taxonomie dans la hiérarchie) alors que si j'ai utilisé la référence d'entité, je ne peux pas penser à un moyen simple de le faire (autre que l'ajout de taxonomie, ce qui entraîne alors une redondance).

J'ai l'impression qu'il y a quelque chose que je ne comprends pas ici, mais je ne suis pas sûr de ce que c'est!

Toute aide serait appréciée.


Ok, j'ai fait quelques progrès dans la compréhension - une référence d'entité peut en fait être un terme de taxonomie! «Équipe B» pourrait donc être à la fois un type de contenu (contenant la description) et un lien de référence d'entité vers un terme de taxonomie (du même nom). Ensuite, un utilisateur pourrait être lié au terme de taxonomie, plutôt qu'au type de contenu ...
James

Je suppose qu'une chose que je n'ai pas encore résolue est - quelle est la différence entre avoir un champ dans un type de contenu qui est un terme de taxonomie, et une référence d'entité qui se relie à un terme de taxonomie - ce dernier semble juste comme un niveau supplémentaire de complication.
James

Ils sont assez comparables. Par cohérence, j'aime utiliser la référence d'entité.
alex laughnan

Mais si vous utilisez la référence d'entité, il y a encore des cas où il vaut toujours mieux utiliser la taxonomie n'est-ce pas? Ainsi, par exemple, si nous avons une hiérarchie organisationnelle, il me semble que la taxonomie est une meilleure façon de procéder.
James

Réponses:


21

Vous parlez ici de deux concepts différents. La première question est liée à chaque fois que l'on veut organiser le contenu en différentes catégories ou si l'on veut établir une relation entre les types de contenu existants. L'autre question est de savoir si, lors de l'utilisation d'une taxonomie, sera-t-il préférable d'utiliser un champ de référence de taxonomie ou un champ de référence d'entité.


Concernant le premier concept

Cela dépend de votre cas d'utilisation. Les taxonomies sont idéales pour créer des hiérarchies, comme vous l'avez mentionné, mais idéalement, vous ne devriez pas utiliser de taxonomies pour contenir du contenu réel. La raison en est simple - bien que vous puissiez ajouter des champs aux termes de taxonomie, tous les niveaux hiérarchiques d'une taxonomie utilisent les mêmes champs. En prenant votre exemple avec des membres appartenant à différentes équipes, cela pourrait entraîner des problèmes. Si vous souhaitez stocker plus d'informations sur une équipe ou un membre que simplement le nom, si, par exemple, vous souhaitez stocker des informations sur le prénom, le nom et la biographie d'un membre et ajouter ces champs à la taxonomie, ils seront également disponible en équipe. Et si vous ajoutez un champ de description d'équipe pour les équipes, celles-ci s'afficheront pour les membres de l'équipe.

Les taxonomies sont mieux utilisées lors de l' organisation hiérarchique d' éléments similaires . Comme les balises, par exemple:

  • légume
    • carotte
    • Patate
  • fruit
    • Pomme
    • banane

Les références d'entité sont excellentes pour établir des relations entre les types de contenu. Les exemples incluent lorsque vous avez un type de nœud «équipe» et un type de nœud «membre de l'équipe», chacun avec ses propres champs. Ou une «chanson» de type nœud qui fait référence à un «album» qui fait lui-même référence à un «musicien». À cet égard, les références d'entité sont plus flexibles que les taxonomies, car elles permettent des relations plus complexes. Lorsque vous utilisez des vues, vous pouvez également utiliser ces relations. En prenant votre exemple, vous pouvez créer une vue de tous les membres de l'équipe et utiliser la référence d'entité pour une relation, et vous pouvez afficher n'importe quel champ du type de contenu d'équipe avec les champs du nœud de membre.

Les nœuds de mélange référencés et les champs de taxonomie sont également légitimes. Dans votre exemple avec les équipes, l'équipe et le membre peuvent être un nœud, se référençant mutuellement avec une référence d'entité. Dans le même temps, le département pourrait être une taxonomie avec tous les départements disponibles.


Concernant le deuxième concept

Lorsque DO a publié D7, il était livré avec un champ de référence de taxonomie à utiliser pour référencer les taxonomies. Depuis lors, nous avons vu la sortie du module API d'entité et, par conséquent, du module de référence d'entité, et puisque les termes et les taxonomies sont des entités, on peut les référencer comme n'importe quelle autre entité. À ce stade, les deux fonctionnent de manière très similaire, et dans de nombreux cas, peu importe celui que vous utilisez. Cependant, il existe encore des modules contribués fournissant des formateurs de champ et des widgets, qui ne fonctionnent que pour l'un ou l'autre. Donc, cela dépend surtout si vous avez besoin d'un tel formateur si vous devez utiliser une référence de taxonomie ou une référence d'entité.

Comme DO remplace le champ de référence de taxonomie par le champ de référence d'entité dans D8, je préfère utiliser le champ de référence d'entité pour établir un lien vers les taxonomies plutôt que le champ fourni par le module de taxonomie.


2
Quelle merveilleuse explication! Merci beaucoup! Maintenant, je comprends!
James
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.