Entité Custom ou Type de contenu (node) ?

Par Le Barman - Mardi 5 février 2019
Tags
Entity
Custome Entity
Node
Vignette

Historiquement, les types de contenus (nodes) étaient (et sont toujours un peu) l'une des pierres angulaires de Drupal, on ne jurait que par eux ! Or depuis Drupal 7 et l'apparition des entités, le doute et la confusion se sont immiscés lorsqu'il faut mettre en place un "nouvel objet" sur un site. Dois-je créer une entité custom ou un nouveau type de contenu ?

Est-ce que:

  • Votre objet doit être révisable
  • Votre objet doit être traduisible
  • Votre objet sera public ou devra répondre à un ensemble de permissions assez simples.
  • Les fonctionnalités de base (et champs qui en découlent) comme promu en page d'accueil, épinglé en haut des listes ou publié vous seront utiles.
  • Vous ajouterez idéalement un nombre limité de champs supplémentaires.

Disons très arbitrairement qu'à partir de 50% de OUI à ces questions, utiliser un node est tout à fait envisageable. À l'inverse en dessous de 50% on peut se demander si le ce choix est pertinent. Il faut alors ajouter la question suivante:

  • Mon objet sera-t-il l'objet d'un process métier spécifique et complexe ? Exemple: une réservation pour un stage ou un appart à louer, ou encore un quiz dans le cas d'un site d'e-learning. 

Mais un Node c'est déjà une entité ?

Bien vu l'aveugle ! Drupal 8 est quasiment intégralement constitué d'entités. Un terme de taxonomie, un bloc, une page, un utilisateur... D'ailleurs si on prend ces entités et qu'on leur applique les questions posées précédemment on s’aperçoit vite qu'un node n'aurait pas été adapté.

Extrait du schema d'héritage des content entities de Drupal 8
Focus sur l'héritage des content entities de Drupal 8.

Sur ce diagramme (caché dans les tréfonds de la doc Drupal) on voit clairement que les entités User, Term ou encore Node héritent de ContentEntityBase qui hérite elle même de Entity la sainte classe mère de toutes. Ainsi on visualise plus simplement que les types de contenus (Node) ne sont pas forcément adaptés à tous les besoins et qu'il peut être bien plus simple de créer notre propre Entité qui héritera de ContentEntityBase.

Comment créer une entité custom ?

C'est là où le bât blesse! Créer la sous-classe de ContentEntityBase ne suffira malheureusement pas! En effet il sera préférable d'ajouter une interface propre à votre entité en plus de différents handlers, templates et formulaires nécessaires à ce que tout s'intègre bien dans votre Drupal. Nous n'allons donc pas aborder ce sujet en détail, d'autres l'ont déjà très bien fait! Sachez simplement qu'à l'usage il est préférable d'utiliser Drupal Console pour cela.
 

N'oubliez pas les Entités de type config et bundle!
 

On ne va pas détailler ça maintenant parce qu'il se fait tard et qu'on a la flemme, sachez simplement que les entités de type config (ConfigEntityBase) sont un peu comme une structure de configuration avancée. En d'autres termes, si le Configuration Storage de Drupal ne vous suffit pas regardez du coté de ces dernières.

 
Quant aux ConfigEntityBundle, elles permettent de déclarer une entité de configuration intermédiaire nécessaire pour avoir différentes bundles de contenu (ContentEntityBase). Cette phrase n'est sans doute pas claire mais pour prendre un exemple le module core drupal/node déclare NodeType comme un ConfigEntityBundle et Node comme ContentEntityBase. C'est grâce à cela que l'utilisateur peut ainsi librement créer des types de nodes (article, pages ...).
Ainsi dans le cas de création d'entité custom Booking (process de réservation) on pourra créer des bookings de type appart, maison, bungalow avec pour chacun de ces sous types de bookings des champs spécifiques et dédiés. Les process métiers complexes et communs pourront en revanche s'appliquer à l’ensemble de ces bookings.

voila on s'arrête là, à la bonne votre!


Le Barman

Commentaires

Ajouter un commentaire

L'e-mail est obligatoire mais restera privé.