À l'origine, les entités, un heureux effet de bord du découplage de la "Field API", sont arrivées très tardivement dans le cycle de développement de Drupal 7. Ce retard a contraint les mainteneurs à laisser certaines fonctionnalités de côté…jusqu'à Drupal 8.

Des objets, partout des objets

Les entités profitent du passage du CMS vers une orientation objet, chaque objet hérite donc d'une série de classes et méthodes unifiées qui permettent de cumuler données et meta-données dans une API cohérente. Grosse nouveauté, ces objets sont itérables, il devient alors possible de développer un traitement générique sur tous les champs d'une entité sans connaître au préalable leur qualité, quantité et/ou leur contenu. Le code devient plus générique et plus simple à maintenir.

Des champs à perte de vue !

Tous ces objets sont maintenant répartis en deux catégories, entités de configuration et entités (~ de contenu). Les entités de configuration sont stockées dans le système de configuration qui ne réside pas principalement dans la base de données. Elles gèrent la configuration de la totalité du dispositif, sont exportables vers des fichiers et peuvent être synchronisées entre différents environnements. Ces entités concernent par exemple les taxonomies, les types de contenus, les formulaires de contacts…

La seconde catégorie d'entités gère le contenu à proprement parler, elles sont constituées de champs par défaut et de champs configurables qui peuvent avoir (nouveauté) des révisions et des traductions. Ces champs configurables sont dorénavant découplés : le stockage, l'affichage et le formatage du champs sont indépendants et modifiables. Ce découplage permet une nouveauté : les champs sont définis par entité ! Il est dès lors possible d'avoir deux champs portant le même nom et des données totalement différentes ce qui, sur Drupal 7, était impossible.

Des entités polyglottes

L'arrivée de l'internationalisation dans le cœur amène sa couche d'accès aux différentes versions d'une même entité. Il devient alors très simple d'aller chercher une entité dans une langue différente ou de récupérer les informations d'une entité selon le contexte et la langue courante via l'EntityManager.

La sauvegarde embarquée et transparente

L'une des grandes nouveauté réside dans la présence du moteur de stockage au niveau de l'entité (et plus au niveau du champ) permettant de changer celui-ci selon le type et le contexte. On peut alors par exemple imaginer avoir des entités spécifiques chargées sur un moteur optimisé pour la recherche ou des moteurs spécialisés embarquant des fonctionnalités avancée type GIS sur un même projet.

L'abstraction SQL permet de gérer automatiquement le schema en se basant sur les informations fournies par les champs garantissant l'accès et la sauvegarde des données. Pour plus d'explications sur le stockage des entités, consultez le lien suivant.

Pour l'accès aux données, il existe dorénavant un objet EntityQuery très similaire à l'EntityFieldQuery de Drupal 7. Il permet le requêtage avec le support de différentes langues, des relations, des aggrégations, autant d'opérations SQL classiques mais dorénavant mieux liées aux entités et à leurs méta-données.

La validation à la demande

La dernière de ces nouvelles API (de loin la plus intéressante) est matérialisée par la Validation API, elle-même basée sur le Symfony Validator. Grâce à cette API il devient alors possible de valider les champs d'une entité en se referrant aux déclarations des champs à l'unité.

Cette validation vient sans aucun coût de développement supplémentaire puisque les champs définissent leurs formats et leurs validations de manière à assurer la cohérence de la base de données. Mais nous pouvons également définir nos propres règles de validation. Chaque champ existant peut dès lors se voir ajouter une validation, chaque nouveau champ déclaré peut utiliser les validations des champs existants ainsi que de nouvelles basées sur des règles dépendantes du projet.

Mais l'API ne s'arrête pas là ! Puisque les validations prennent la forme de plugins, elles peuvent être réutilisées à plusieurs niveaux. Ainsi les entités ont aussi accès à leur validation permettant des cas plus complexes impliquant plusieurs champs, du contexte externe ou évitant par exemple deux éditions concurrentes d'un même noeud.

Il est également à noter que la Validation API est totalement découplée des formulaires. Ce qui semble être un détail favorise la réutilisation des contraintes déclarées dans les API REST en conservant les mêmes entités.

Conclusion

Au final, cette nouvelle Entity API est plus cohérente. Elle permet plus de mutualisation du code et laisse la part belle aux méthodes objet, à l'héritage et la mutualisation du code. Autant de modèles de conception qui facilitent la maintenance et la réutilisation !

Vous pouvez retrouver les slides de la presentation en suivant ce lien.