Quand est-il approprié de créer une entité plutôt que d'ajouter simplement un nouveau type de contenu?
Quel est l'avantage de créer de nouveaux types d'entités par rapport à la création d'un nouveau type de contenu?
Il semble un peu exagéré de faire tout le codage personnalisé qui est nécessaire pour créer une nouvelle entité lorsque toutes les fonctionnalités CRUD et Views sont déjà intégrées aux types de contenu.
Il ne s'agit pas tant de savoir quels sont les avantages mais plutôt de savoir ce qui convient à une situation particulière comme vous l'avez dit. Vous pouvez représenter à peu près n'importe quoi avec un nœud et pour 99% des situations (comme je l'ai trouvé au moins), vous n'aurez pas besoin d'implémenter des types d'entités personnalisés.
Je pense toujours au taxonomy_term le type d'entité comme un bon exemple de pourquoi tout ne devrait pas être un type de nœud/contenu:
Un terme de taxonomie est essentiellement destiné à regrouper différentes entités et, en tant que tel, ne nécessite pas la même fonctionnalité qu'un nœud. Alors que vous pourriez théoriquement utiliser un type de contenu pour effectuer cette fonctionnalité (avec peut-être un champ de référence de nœud), un terme de taxonomie n'a pas besoin de faire la même chose qu'un nœud, donc il ne fait pas vraiment sens de le faire. La même chose peut être dite pour les user et taxonomy_vocabulary types d'entité.
Ainsi, un terme de taxonomie est créé en tant qu'entité distincte et est programmé pour faire uniquement ce dont il a besoin, tout en bénéficiant des avantages de pouvoir avoir des champs attachés, etc.
Je pense que la réponse simple est que lorsqu'un type de nœud/contenu ne fait pas fait ce dont vous avez besoin, ou si c'est juste une quantité énorme de surpuissance/surcharge pour très peu d'avantages, alors vous devriez choisir de écrire une entité personnalisée.
Ceci est uniquement basé sur mon expérience personnelle; Je serais intéressé d'entendre ce que quelqu'un directement impliqué dans Drupal développement principal avait à dire à ce sujet.
Une règle de base très simple que j'utilise est de savoir si votre contenu doit être affiché publiquement seul. Si c'est le cas, optez pour le nœud, sinon choisissez une entité. Entityforms vous permet désormais de créer une interface pour remplir vos entités.
Par exemple, sur un site Web réalisé avec D6, nous construisons un type de contenu publicitaire (avec son champ d'image, la date d'affichage de début/fin ...), mais ensuite vous devez le rendre non publié par défaut et donnez à vos éditeurs le droit de modifier/visualiser ces nœuds et espérait qu'aucune vue/recherche ne les afficherait sur le monde extérieur. C'est assez lourd et il serait plus facile de traiter avec des entités.
Une entité représente un cas d'utilisation spécifique .
Je crois que le mérite de cette définition simple revient à Fago , mais je suis trop paresseux pour trouver une référence.
Nous pourrions utiliser Content (alias Nodes) pour tous les cas d'utilisation si nous le voulions, mais souvent cela n'a pas de sens.
Content a un auteur et des paramètres pour les commentaires et l'emplacement du menu.
Users, représente un cas d'utilisation suffisamment différent de Content parce que sur un user aucun des éléments ci-dessus n'a de sens, tandis que d'un autre côté, un user doit avoir un e-mail et un mot de passe.
Taxonomy terms se démarquent car ils ont la fonctionnalité intégrée pour être organisés dans une hiérarchie, même circulaire.
Si votre cas d'utilisation est suffisamment similaire à une entité existante, utilisez cette entité. Si votre entité est régie par des règles sensiblement différentes de celles existantes, créez-en une nouvelle.
Il y a aussi An Introduction to Entities , mais malheureusement cela ne répond pas vraiment à votre question.
Je pense que tout dépend du contexte, un nœud est largement utilisé pour le contenu, ce qui serait des blogs, des articles, des FAQ, etc. Tout en étant utilisateur pour des profils comme le personnel, les clients, etc.
- Forum
- Projet (en termes de gestion de projet)
- Forme
- Billet d'assistance
- Groupe
Bien que vous puissiez utiliser un nœud pour quelque chose comme un ticket de support, ce n'est peut-être pas le meilleur modèle et les meilleurs paramètres par défaut ... J'espère que cela vous aidera.
Les entités peuvent être créées avec moins de surcharge que les nœuds car elles n'ont pas besoin d'avoir toutes les fonctionnalités robustes dont disposent les entités.
Cela signifie également que le stockage peut être plus simple - vous pouvez les créer pour récupérer toutes les informations dans une simple requête sans JOINS si vous le souhaitez. Tous les champs joliment dans une seule table bien rangée.
Cela peut être un énorme avantage si vous avez beaucoup de fonctions qui doivent effectuer des requêtes sur les entités et que vous mettez à jour de nombreuses entités simultanément avec les requêtes UPDATE dans la base de données. Si vous pouvez vous assurer que les données sont relativement autonomes dans une seule table, vous avez moins de soucis et de possibilités de corruption de données.
Un type de contenu est conçu pour être du contenu de site. Autrement dit, chaque type de contenu est conçu pour être publié et apparaître sur le site. Par exemple, un article (prêt à l'emploi) est conçu pour apparaître sur la première page.
Supposons maintenant que vous souhaitiez créer un formulaire de demande d'emploi ou d'appartement. De toute évidence, vous ne voudriez pas publier la demande d'emploi de quelqu'un sur votre site Web. Et si vous vouliez créer une liste de contacts clients/prospects? Souhaitez-vous prendre le risque que ces informations soient publiées par erreur sur votre site Web? Personnellement, je ne le ferais pas.
Par conséquent, le module de formulaire d'entité qui est discuté ci-dessus. Il vous permet de créer un type d'entité qui n'est pas conçu pour être un contenu. Cependant, ces types d'entités sont disponibles pour tout module qui prend en charge des entités telles que des règles, des vues et un groupe organique pour n'en nommer que quelques-unes.
Et puis vous entrez dans Drupal Commerce où les produits sont des types d'entité. Fondamentalement, les entités permettent aux développeurs d'étendre Drupal d'une manière jamais prévue par l'original Drupal.
Ceci est sujet à discussion et à la fin, vous devez prendre vos décisions en tant que développeur.
Je choisis des entités sur des nœuds chaque fois que les données ne doivent pas être accessibles au public avec leur propre URL. Les nœuds obtiennent par défaut un alias d'URL, un statut publié, un titre, des balises META, ... tandis que les entités obtiennent simplement un enregistrement dans la base de données.
"Je veux pouvoir ajouter autant de bannières que possible avec du texte, puis dans un article de blog, choisir entre l'une d'elles"
- Le type de contenu serait "Blog"
- L'entité personnalisée serait "Élément de bannière"