Avec l'état D8 actuel, quel est l'arbre de décision pour la création d'un nouveau type d'entité de contenu par rapport à la création d'un type de contenu pour l'entité de contenu «Node»?

Nous avons vu quatre ans et la première version de Drupal 8 depuis que la réponse acceptée a été écrite pour la question " Quand est-il approprié de créer une entité plutôt que d'ajouter simplement un nouveau type de contenu ?" Et, les entités sont plus centrales dans Drupal 8 qu'elles ne l'étaient dans Drupal 7. ( RefB , RefC , RefD )

Dans ce nouveau monde Drupal 8, quel est l'arbre de décision pour créer un nouveau type d'entité de contenu par rapport à un nouveau type de contenu pour l'entité de contenu de type "Node"?

Lorsque vous envisagez une réponse, veuillez considérer les éléments suivants:

• Un nouveau type de contenu pour le type d'entité de contenu "Node" est-il toujours approprié dans 99% des situations par rapport à un nouveau type d'entité de contenu?
• L'arbre de décision inclut-il désormais des raisons plus nombreuses, meilleures ou plus claires de s'éloigner de l'utilisation du type d'entité de contenu "Noeud" et de créer un nouveau type d'entité de contenu? Et si oui, quels sont-ils? Comprennent-ils:
  • Performance?
  • Sécurité / autorisations?
  • Le nombre de modules qui fonctionnent avec les types de contenu de type entité-nœud et ne fonctionnent pas avec d'autres types d'entités de contenu?
• Peut-être - sur la base de la réponse acceptée précédente référencée ci-dessus - que la seule raison générale de faire un type d'entité de contenu personnalisé est si vous souhaitez grouper les données de nœud, par exemple avec des termes de taxonomie, ou annoter autrement le nœud, par exemple avec des commentaires?

La compatibilité des modules semble être une considération particulièrement intéressante pour un arbre de décision. À l'heure actuelle, peu des modules les plus installés ont une version 8.x qui n'est pas simplement alpha, bêta ou rc (une version candidate). Et il semble difficile d'identifier combien d'entre eux fonctionneront prêts à l'emploi avec un nouveau type d'entité personnalisé par rapport à un nouveau type de contenu d'entité Node. Il ne semble pas y avoir d'attribut de projet pour faire la distinction entre ceux qui sont "écrits pour les entités" et "écrits pour les types de contenu d'entité de nœud".

Jetez un œil à pathauto, qui est actuellement le quatrième module le plus installé de ceux qui ont tout type de version 8.x. Les gens travaillent dur sur une version 8.x qui prend généralement en charge les entités et pas seulement les types de contenu de type entité-nœud. Mais qu'en est-il de tous les autres modules? Et les modules qui prennent en charge les entités vont-ils généralement nécessiter des types d'entités de contenu personnalisé pour avoir des "hooks" spécifiques au module avant que le module ne fonctionne avec eux? (Par rapport à la façon dont les modules peuvent simplement fonctionner directement avec de nouveaux types de contenu?) Cela semble être le genre de défi avec lequel l'équipe de pathauto travaille, et c'est peut-être une raison de s'éloigner d'un type d'entité de contenu personnalisé?

Il peut également être utile de mentionner que Drupal 8 core contient une interface utilisateur pour créer de nouveaux types de contenu pour l'entité de contenu de type "Node", mais il ne contient pas actuellement une interface utilisateur pour créer de nouveaux types d'entités de contenu. ( RefX , RefY , RefZ )

Arbre de décision pour choisir entre la création d'un nouveau type de contenu de type entité nœud et un nouveau type d'entité contenu:

1. Êtes-vous un programmeur ou avez-vous facilement accès à un programmeur?
   • Si non, vous êtes actuellement à peu près limité à la création de nouveaux types de contenu d'entité nœud. (Il n'y a pas d'interface utilisateur de base pour créer de nouveaux types d'entités de contenu, et le module de contribution ECK (Entity Construction Kit) n'a actuellement qu'une version alpha.)
   • Si oui, alors continuez ...
2. Savez-vous exactement quels modules contrib vous souhaitez exploiter pour vos données?
   • Si non, alors le pari sûr est probablement de simplement créer un type de contenu d'entité nœud.
   • Si oui, ces modules prennent-ils déjà en charge le (s) type (s) d'entité personnalisé (s) que vous envisagez, ou êtes-vous prêt à contribuer à leur amélioration afin qu'ils recréent ou recréent la fonctionnalité souhaitée dans votre module?
     • Si non, la création d'un type de contenu de type entité-nœud peut être la meilleure solution pour vous.
     • Si oui, alors continuez ...
3. Les données de contenu réelles activées par votre module aideront-elles simplement à regrouper ou annoter d'autres données de contenu? (De sorte qu'il sera rarement vu seul.)
   • Si oui, vérifiez si votre module est similaire aux types d'entités existants pour les termes et commentaires de taxonomie. Si tel est le cas, un nouveau type d'entité peut être une valeur sûre.
   • Si non, continuez ...
4. Pouvez-vous expliquer clairement pourquoi un nouveau type de contenu de type entité-nœud ne fonctionnera pas pour vous?
   • Si non, votre pari sûr est probablement de simplement créer un nouveau type de contenu de type entité-nœud.
   • Si oui, alors continuez ...
5. Enfin, êtes-vous sûr que vous ne pouvez pas simplement étendre le type d'entité Node et que vous souhaitez recréer toutes ses fonctionnalités utiles comme les opérations CRUD?
   • Si oui, alors allez-y et créez un nouveau type d'entité personnalisé.
   • Si non, ou si vous n'êtes pas sûr, vous voudrez probablement engager des experts pour vous aider à décider.

Remarques:

1. Cet arbre de décision ne prend pas en compte les performances ou la sécurité. Je ne sais pas si ou quand un nouveau type d'entité de contenu personnalisé fonctionnerait mieux et serait plus ou moins sécurisé qu'un type d'entité Node.
2. Même si cet arbre est une bonne réponse, il ne le restera probablement pas dans le temps en raison des mises à jour dans les versions du noyau Drupal et du module contrib. StackExchange ne semble pas comprendre comment la "meilleure" réponse aujourd'hui peut ne pas être la meilleure réponse demain.)

Une approche simple à ce sujet consiste à prendre en considération l'objectif du projet, sa taille et les exigences commerciales.

1. Comment le type de contenu d'entité de nœud par défaut affecte la construction du projet d'une manière simple et nette plus proche de l'architecture et des flux de données produits à partir de la réflexion analytique des documents du projet.

Un avis important ici, la décision de créer un nouveau type d'entité est généralement prise par les développeurs ou les responsables techniques et non par les constructeurs de sites ou les propriétaires de projets qui gèrent l'application et se concentrent uniquement sur les affaires.

2. Drupal 8 dépend de certains packages symfony2 et est plus proche des frameworks, développement que les cms traditionnels parlent de Drupal avec de grands changements architecturaux, j'envisage qu'il est préférable de construire une nouvelle entité que de faire de nombreuses personnalisations et configurations complexes sur des types de contenu d'entité de nœud dans l'ordre pour tirer parti de Drupal parmi d'autres cadres, car beaucoup de gens n'aiment pas la façon dont la configuration Drupal et les paramètres distribués, vous pouvez rencontrer des gens provenant de WordPress et utilisés pour configurer tout à partir d'un seul formulaire, ce qui les rend agacés lorsqu'ils traitent avec le tableau de bord d'administration Drupal.

3. Drupal 9 prévoit de supprimer totalement le système de hook et de le remplacer par un répartiteur d'événements qui conduit à un grand besoin d'une interface d'administration pour créer une nouvelle entité car la modification des fonctionnalités existantes du code sera beaucoup plus difficile pour les personnes qui ne sont pas développeurs et sera très essentielle pour ajoutez cette fonctionnalité.

À la fin , je vois que de nouvelles entités adaptées aux besoins du projet offrent de meilleures performances que les types de contenu complexes avec un grand nombre de champs, car chaque champ ajoute maintenant 2 tables à la base de données et doit charger sa configuration à chaque demande, en particulier avec le une logique métier lourde est requise.

Clair et simple: ce n'est pas tout le contenu. La liste du contenu peut être assez longue et déroutante si vous utilisez uniquement des types de contenu. ( ContentEntityBase peut également être implémenté par une entité personnalisée)

Si vous avez un auteur et un état publié, vous devez opter pour un type de contenu.

Sinon (en supposant que vous soyez un programmeur), les entités personnalisées devraient être préférées. Beaucoup peut être facilement implémenté avec toutes les interfaces (comme révisable, exploitable sur le terrain, restriction d'accès, etc.)

À mon avis, c'est juste une architecture plus claire et ordonnée (et aussi plus performante).

En pensant à la réutilisabilité dans plusieurs projets, l'effort de faire exploser les entités personnalisées .. il y a aussi des aides astucieuses comme drupal-code-generator . Pour garder le codage personnalisé (ou la complexité) à un bas niveau, vous devriez envisager d'utiliser des types de contenu si vous le souhaitez:

• Pour traduire «l'entité» (au moins en D7), il y aurait aussi une interface.
• (ouvert aux suggestions) ..

C'est une question difficile qui honnêtement, je pense, n'est comprise qu'une fois que vous l'avez mise en œuvre auparavant. Mais comme remy l'a mentionné, tout n'est pas brut, le contenu est destiné aux utilisateurs .

Dans Drupal 7, la possibilité de créer des entités personnalisées existait, mais pourrait être une tâche intimidante si vous étiez rude sur les bords avec la POO. Il a été en quelque sorte à moitié mis en œuvre (ou à moitié fait, comme vous voulez le dire), ce qui a conduit à des moyens de créer des entités qui n'étaient pas toutes exactement uniformes et convenues, avec des procédures et des procédures d'exploitation mixtes.

Dans Drupal 8, l'idée est beaucoup plus concrétisée et il est beaucoup plus facile de démarrer et de fonctionner avec une entité personnalisée. Le nœud lui-même est basé sur ContentEntityBase, tout comme les blocs, les utilisateurs, les fichiers et la taxonomie.

Les nœuds sont spécifiquement destinés aux données de contenu publiées, visibles (ou autorisées) qui agissent généralement comme du contenu (c'est-à-dire dans un menu ou dans le plan du site, ou le plan du site xml, ou les flux RSS, etc.). Drupal a été conçu de manière à ce que vous puissiez vous connecter à n'importe quelle étape du processus des opérations de nœud et le modifier, ce qui peut avoir des conséquences inattendues si vous avez une mauvaise combinaison de modules contribués. C'est probablement une opinion controversée, mais cela aide à vous séparer de l'idée de "tout est un nœud" afin d'embrasser davantage le concept d'entité.

Contenu idéal qui fait d'excellents types de contenu:

• Article
• Page
• Offre d'emploi
• un événement
• Page de destination
• Page d'accueil

Le fil conducteur pour eux est qu'ils partagent un concept d'un type de contenu. Il est généralement dans un certain nombre d'états de flux de travail (publié, promu, collant, archivé, présenté, etc. - si vous utilisez des options de publication personnalisées), et un grand nombre de modules apportés interagissent directement avec lui, comme Pathauto.

Mais supposons que vous souhaitiez stocker des données dans Drupal qui sont internes, privées, entraînent d'autres données ou des données qui ne devraient pas autoriser l'intégration en dehors de sa portée, sauf si vous l'autorisez. De quel type de données s'agit-il? Voici quelques types possibles:

• Produit (Drupal Commerce)
• Élément de campagne (Drupal Commerce)
• Serveur de recherche (ApacheSolr / SearchAPI)
• Contact (comme le responsable CRM)
• Ticket (comme le ticket d'assistance)

Qu'est-ce qui les rend si différents? Pourquoi voudriez-vous une entité pour le contact, au lieu d'utiliser le modèle utilisateur? Vous pouvez faire quelques arguments, mais mon exemple serait que si vous dites, en collectant des adresses e-mail et des noms et d'autres métadonnées à partir d'un formulaire de contact, stockez ces données en tant qu'entité personnalisée. Vous empêchez la liste d'utilisateurs d'être polluée par des éléments non liés au compte, vous réduisez les problèmes de sécurité potentiels (que se passe-t-il si un script ou quelqu'un met accidentellement à jour ces comptes pour qu'ils soient des administrateurs ou envoie un courrier de masse?), Vous effectuez une gestion interne des frais généraux de l'utilisateur réel comptes plus faciles, et vous segmentez ce que vous capturez à ce que c'est, un peu spécialisé de données.

À partir de là, il est largement dissocié des parties les plus automatiques du système Drupal / Node et vous pouvez personnaliser les actions et l'expérience. Vous déterminez les itinéraires, l'accès et le workflow CRUD.

Dans cet état d'esprit, il est plus facile de comprendre pourquoi l'approche à cet égard se ferait de cette façon. Prenons l'exemple du ticket de support - il s'agit de demandes entrantes, mais ce ne sont pas des données publiées, et a probablement un flux de travail très spécifique qui est plus facile à configurer que de le séparer des parties du système de nœuds que vous ne voulez pas qu'elles adhèrent à.

Un autre exemple serait les données externes importées. Dans la plupart des cas, ces données ne sont généralement pas enrichies avec des données Drupal locales (même si elles le sont, en tant qu'entité, vous pouvez toujours le faire). Ça pourrait être n'importe quoi. Peut-être que ce sont des factures, peut-être que ce sont des livres, peut-être que cela tire des marques de bière.

De telles données sont généralement spécifiques et nécessitent un contrôle au-delà de ce à quoi le nœud est destiné. Cela ne veut pas dire que vous ne pouvez pas l'augmenter en utilisant un champ de référence sur un nœud pour pointer vers votre entité personnalisée (c'est ainsi que Drupal Commerce a travaillé, à un certain niveau) pour enrichir les données. Dans le même temps, vous isolez et assurez le contrôle de vos données et de l'interface utilisateur du code contrib errant allant au-delà de sa conception et interférant avec votre modèle. C'est probablement moins un problème en D8 qu'il ne l'était en D7, bien que certains crochets restent.

L'architecture appropriée existe maintenant pour encourager la séparation. Tout n'est pas un nœud.