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 exagéré de faire tout le codage personnalisé nécessaire à la création d'une nouvelle entité lorsque toutes les fonctionnalités CRUD et Vues sont déjà intégrées aux types de contenu.
Réponses:
Il ne s'agit pas tant de savoir quels sont les avantages, mais plutôt de déterminer ce qui convient dans une situation donnée, comme vous l'avez dit. Vous pouvez représenter à peu près n'importe quoi avec un nœud et dans 99% des situations (comme je l'ai au moins découvert), vous n'avez pas besoin d'implémenter des types d'entité personnalisés.
Je pense toujours au taxonomy_termtype d'entité comme un bon exemple de la raison pour laquelle tout ne devrait pas être un type noeud / contenu:
Un terme de taxonomie est essentiellement destiné à regrouper différentes entités et ne requiert donc pas la même fonctionnalité qu'un nœud. Bien que vous puissiez théoriquement utiliser un type de contenu pour exécuter 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, cela n'a donc aucun sens de le faire. La même chose peut être dite pour les types d'entité useret taxonomy_vocabulary.
Ainsi, un terme de taxonomie est créé en tant qu'entité distincte et est programmé pour ne faire que ce dont il a besoin, tout en obtenant les avantages de pouvoir avoir des champs attachés, etc.
Je pense que la réponse simple est que lorsqu'un nœud / type de contenu ne fait pas ce dont vous avez besoin, ou qu'il s'agit simplement d'une surcharge énorme / surcharge pour un bénéfice minime, vous devez alors choisir d'é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 le développement de Drupal a dit à ce sujet.
J'utilise une règle très simple: votre contenu doit-il être affiché publiquement seul? Si c'est le cas, optez pour noeud, sinon choisissez une entité. Entityforms vous permet maintenant de créer une interface pour remplir vos entités.
Par exemple, sur un site Web créé avec D6, nous construisons un type de contenu de publicité (avec son champ d’image, la date de début / fin d’affichage, etc.), mais vous devez ensuite le rendre non publié par défaut et donner à vos éditeurs les droits de modification. / view this node et espère qu'aucune vue / search ne les affichera dans 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 pense que le mérite de cette définition simple va à 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 assez différent de celui-ci Contentcar useraucun de ce qui précède n'a de sens, tandis que, d'autre part, un usere-mail et un mot de passe sont indispensables.
Taxonomy terms se démarquent car ils ont la fonctionnalité intégrée pour être rangé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 très différentes de celles existantes, créez-en une nouvelle.
Il existe également une introduction aux entités , mais malheureusement, cela ne répond pas vraiment à votre question.
Je pense que tout est une question de contexte. Un nœud est largement utilisé pour le contenu. Il s’agit donc de blogs, d’articles, de faq, etc. Tout en étant utilisateur de profils tels que personnel, clients, etc. Exemple de création d’une nouvelle entité:
Bien que vous puissiez utiliser un nœud pour quelque chose comme un ticket d'assistance, il se peut que ce ne soit 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 charge que les nœuds car elles n'ont pas besoin de toutes les fonctionnalités lourdes dont disposent les entités.
Cela signifie également que le stockage peut être plus simple: vous pouvez les créer pour saisir toutes les informations dans une requête simple sans JOINS si vous le souhaitez. Tous les champs joliment dans une seule table rangée.
Cela peut présenter un avantage considérable si de nombreuses fonctions doivent effectuer des requêtes sur les entités et si vous mettez à jour plusieurs entités simultanément avec des 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 aurez moins de soucis et de possibilités de corruption des données.
Un type de contenu est conçu pour être le contenu du site. C'est-à-dire que 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 quelque chose comme 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. De plus, si vous vouliez créer une liste de contacts clients / principaux? Voudriez-vous courir le risque que cette information soit publiée par erreur sur votre site Web? Personnellement, je ne le ferais pas.
Par conséquent, le module de formulaire d'entité décrit ci-dessus. Cela vous permet de créer un type d'entité qui n'est pas conçu pour être contenu. Cependant, ces types d'entités sont disponibles pour tout module prenant en charge des entités telles que des règles, des vues et des groupes organiques, pour n'en nommer que quelques-uns.
Et puis vous entrez dans Drupal Commerce où les produits sont des types d'entités. En gros, les entités permettent aux développeurs d'étendre Drupal d'une manière jamais prévue par les concepteurs Drupal d'origine.
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 lorsque 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 méta, ... 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 l'une d'entre elles"
Entité vs contenu
L'entité a des ensembles d' entités qui ont des champs
Le contenu est un type d'entité. Alors,
Le contenu contient des ensembles de contenu (article, page) comportant des champs (corps, image de l'article).
Si vous êtes programmeur, vous choisissez sûrement le chemin de création de votre propre entité, mais pour les constructeurs de sites, ce n'est peut-être pas le meilleur chemin à suivre. Encore une fois, pour les constructeurs de sites, il existe une interface utilisateur pour créer Entity http://drupal.org/project/eck