9.14. Écriture d’une intégration avec Views
Le module Views est largement utilisé dans l’écosystème Drupal. Listes de contenus, tableaux, blocs, diaporamas, exportation de données — ces contenus sont généralement affichés avec Views. Si vous utilisez des types de contenu, types de blocs ou d’autres types d’entités, Views est déjà intégré automatiquement avec eux et vous pouvez utiliser Views pour afficher votre contenu. Mais pour votre module personnalisé, où vous utilisez une table de base de données séparée, créée avec hook_schema(), vous devez écrire une intégration avec Views pour afficher les données de votre module dans l’interface de Views.
Voyons l’intégration pour le module Did this help avec Views :
https://www.drupal.org/project/did_this_help
Le module crée sa propre table de base de données pour stocker les données. Dans cette table se trouvent des chaînes, des IDs, des dates, donc nous devons définir différents gestionnaires pour l’intégration avec Views :
Au début, vous devez ajouter un fichier MODULENAME.views.inc, qui est chargé automatiquement, donc vous n’avez pas besoin de spécifier son emplacement ailleurs. Dans ce fichier *.views.inc, vous devez implémenter hook_views_data() :
<?php
/**
* @file
* Fournit les données Views pour did_this_help.module.
*/
/**
* Implémente hook_views_data().
*/
function did_this_help_views_data() {
}
Pour cette implémentation, vous devez retourner un tableau décrivant la structure de la table personnalisée de votre module personnalisé.
Commencez avec le nom de la table en première clé du tableau :
$data['did_this_help'] = [
'table' => [
'group' => t('Did this help?'),
'base' => [
'field' => 'id',
'title' => t('Did this help? entries'),
'help' => t('Contient la liste des entrées Did this help?.'),
],
],
];
Voici la description de la table avec le nom dans la clé du tableau $data['did_this_help']. Si vous devez ajouter une intégration avec plusieurs tables, ajoutez différentes clés dans le tableau $data : $data['did_this_help1'], $data['did_this_help2'].
Ensuite, dans la description 'table', on trouve :
group – permet de regrouper les champs dans une même section pour faciliter la sélection des champs dans l’interface Views.
base – indique l’ID sériel de cette table, utilisé plus tard pour joindre des tables via des clés étrangères.
Après cela, on décrit chaque champ que l’on souhaite voir dans Views :
$data['did_this_help']['id']= [
'real field' => 'id',
'title' => t('ID de l’enregistrement Did this help?'),
'help' => t('Enregistrement Did this help?.'),
'field' => [
'id' => 'standard',
],
'sort' => [
'id' => 'standard',
],
'filter' => [
'id' => 'numeric',
],
'argument' => [
'id' => 'numeric',
],
];
real field – permet de définir le vrai nom du champ (colonne dans la table). Si vous utilisez des alias dans les clés du tableau, cela est nécessaire. Pour un type de champ Drupal, les champs réels peuvent avoir plusieurs valeurs, par exemple un champ Lien possède deux valeurs Title et URI, correspondant à deux colonnes dans la table (nom du champ + propriété comme title, uri) :
Les noms de ces colonnes sont créés automatiquement par le module Lien, mais pour les modules personnalisés, vous devez définir vous-même les valeurs de real field dans hook_views_data().
title, help – informations pour l’interface utilisateur de Views.
Ensuite viennent les handlers (gestionnaires) pour : field, sort, filter, argument. Un handler définit la manière de filtrer et d’afficher les champs, par exemple les dates doivent être affichées avec un format Date et filtrées avec un calendrier popup. Pour les nombres, il faut des filtres avec les opérateurs >, < et =, pour les chaînes un filtre par longueur de chaîne.
Handlers de champs
Les handlers de champs aident à générer la partie de la requête SQL après le mot-clé SELECT.
La liste des handlers de champs du module Views dans le noyau Drupal est disponible ici :
Pour les modules personnalisés, vous utiliserez souvent le handler standard pour les nombres et chaînes, et le handler date pour les champs de type date.
Par exemple, le champ ID utilise le handler "standard" :
'id' => [
'real field' => 'id',
'title' => t('ID de l’enregistrement Did this help?'),
'help' => t('Enregistrement Did this help?.'),
'field' => [
'id' => 'standard',
],
'sort' => [
'id' => 'standard',
],
'filter' => [
'id' => 'numeric',
],
'argument' => [
'id' => 'numeric',
],
],
Handlers de tri (sort handlers)
Les handlers de tri permettent d’utiliser le tri habituel et le tri exposé dans Views. Ils définissent la partie SQL de la requête après ORDER BY.
La liste des handlers de tri est disponible ici :
Handlers de filtre
Les handlers de filtre aident à afficher les filtres habituels, exposés et contextuels dans Views. Ils définissent la partie SQL de la requête après WHERE.
La liste des handlers de filtre est disponible ici :
Pour filtrer des dates avec un calendrier popup, vous pouvez utiliser le handler "date" :
$data['did_this_help']['created'] = [
'title' => t('Date de création de l’enregistrement Did this help?'),
'help' => t('Date de création de l’enregistrement Did this help?'),
'field' => [
'id' => 'date',
],
'argument' => [
'id' => 'date',
],
'filter' => [
'id' => 'date',
],
'sort' => [
'id' => 'date',
],
];
Handler de relation (relationship handler)
Les handlers de relation permettent d’ajouter des jointures dans la requête SQL pour récupérer des données de plusieurs tables en une seule requête.
La table de la base de données du module Did this help? contient une colonne avec des IDs utilisateurs. En utilisant un handler de relation, vous pouvez ajouter une relation dans l’interface Views entre les enregistrements de did_this_help et les utilisateurs, et afficher des données de plusieurs tables :
$data['did_this_help']['uid'] = [
'title' => t('ID utilisateur pour l’enregistrement Did this help?'),
'help' => t('ID utilisateur pour l’enregistrement Did this help?'),
'field' => [
'id' => 'standard',
],
'sort' => [
'id' => 'standard',
],
'filter' => [
'id' => 'numeric',
],
'argument' => [
'id' => 'numeric',
],
'relationship' => [
'title' => t('Utilisateur'),
'help' => t('L’utilisateur auquel la ligne de log correspond.'),
'base' => 'users_field_data',
'base field' => 'uid',
'id' => 'standard',
],
];
Pour cela, on ajoute une relation pour le champ, où on spécifie la valeur base avec la table à joindre, le champ pour la jointure base field, le title et le help pour l’interface Views, ainsi que le type de handler id. La liste des types de relations est disponible ici :
Cependant, Views offre une large gamme de handlers différents. Vous pouvez hériter de la classe de base d’un handler et écrire votre propre handler personnalisé pour un champ, un filtre ou un tri. Dans l’article suivant, nous écrirons un handler personnalisé pour un filtre Views.