Drupal et les structures de données

L'une des fonctionnalités qui place Drupal à part d'autres CMSs et frameworks est sa capacité à modéliser facilement les données. Que ce soit pour personnaliser les données utilisateurs ou bien créer une structure de données sur mesure, Drupal propose tous les outils nécessaires. Explorons donc les possibilités qu'offre ce CMS bien particulier.

Lors de la conception d'un site ou d'une application web, l'une des questions centrales est de savoir quelles informations on souhaite publier. S'agit-il de simples articles de blog, de produits commerciaux, de services/prestations ? Drupal est un CMS extrêmement flexible et puissant quant à la modélisation des données. Quels sont les outils à notre disposition ?

Afin de décrire les structures de données dont on a besoin, on dispose de deux outils du coeur de Drupal : Entity API et Database API. Avec Entity API, tout ou presque est pris en charge par Drupal (formulaires CRUD, contrôle d'accès, stockage...), alors qu'avec Database API c'est à vous de décrire ce dont vous avez besoin en base et de gérer ensuite l'affichage, les opérations CRUD, les accès, etc...

Entity API

Drupal propose la notion de types d'entité, c'est à dire les différents types d'objets. On ne parlera pas ici des entités de configuration, mais uniquement des entités de contenu, même si les deux sont bien liés. Ces objets représentent le contenu au sens large, c'est à dire les noeuds, termes de taxonomie, profils utilisateurs, média... Tous ces objets sont construits sur une base commune qui prend en charge nombre de fonctionnalités :

• création automatique des formulaires CRUD.
• gestion des champs pour chaque type d'entité et les bundles correspondants.
• traduction.
• gestion des différentes versions si nécessaire (workflow).
• intégration avec le module Views.
• mise en cache automatique au niveau de l'affichage.
• contrôle d'accès.
• ...

Notons que l'on peut aussi utiliser Entity API, pour ses propres structures de données, mais que cela n'implique pas l'utilisation de Field API. Il est possible de décrire les propriétés de base sans pour autant faire usage de l'ajout de champ via le back-office. Ainsi on évite d'avoir de multiple tables en base, ce qui a un impacte négatif sur les performances (requêtes en base complexes impliquant de très nombreuses tables différentes). Cette utilisation d'Entity API, sans Field API, permet une intégration complète à Drupal en évitant certaines lourdeurs dues au modèle de tables en base.

Database API

D'un autre côté, lorsque l'on a besoin de stocker des données en base, on a à disposition Database API, qui permet d'abstraire la base et de gérer les éventuelles mises à jour du schéma. C'est un système donc plus simple qu'Entity API, mais qui se révèle suffisant dans certains cas; par exemple, le module Ban l'utilise.

Pour déclarer de nouvelles tables depuis un module, on utilise le hook_schema(), qui permet de s'abstraire du type de moteur de base de données. De plus, les hook_update_N() ajoute la possibilité de faire évoluer son schema sans avoir de requêtes à faire en base ni de module à ré-installer.

Notons qu'il est possible d'exposer ses propres tables au module Views, ce qui permets de simplifier l'affichage des données correspondantes. Ceci n'est pas automatique mais reste facile à réaliser et très pratique. Il suffit de définir le Views Handler dans la définition d'une entité ou bien d'utiliser le hook_views_data().

Conclusion

Lorsque vous devez modéliser vos données avec Drupal, c'est à vous de choisir l'une ou l'autre de ces deux solutions. Il est très important de comprendre les implications que cela entraine, car les impactes au niveau fonctionnel sont importants.

Parmi les nombreux avantages de Drupal, ce modèle de données très flexible est bien l'une de ses forces.