Submitted by ineation on
Les relations permettent d'étendre la requête pour inclure des objets qui ne sont pas dans la requête de base. Ce qui rend ce concept un peu difficile à comprendre, c'est que Views utilise déjà quelques relations par défaut, mais sans les afficher. Pour des raisons historiques, il serait maintenant difficile de retirer ces relations par défaut.
Quand des relations sont définies, tous les champs, (y compris les relations elles-mêmes) héritent d'un nouveau paramètre permettant de sélectionner quelle relation ils utilisent. Par défaut ils n'en utilisent pas.
L'exemple typique de la relation qui est disponible par défaut mais qui n'est pas montrée, est celle qui lie le noeud à son auteur via la relation node - utilisateur. Si un noeud est dans une requête, l'utilisateur qui a créé ce noeud est automatiquement accessible dans la vue. [Il est à noter que l'auteur de Views considère que c'est une erreur d'avoir rendu cette relation automatique, mais quand il s'est rendu compte de son erreur, il était déjà trop tard pour la corriger].
Une relation similaire, mais qui elle n'est pas automatique est la révision de noeud. Chaque révision a un auteur, à savoir l'utilisateur qui l'a créée. En ajoutant la relation "Révision du nœud : Utilisateur", tous les champs, critères de tri, filtres et arguments liés à l'utilisateur auteur de la révision deviennent disponibles.
Quand une relation est ajoutée à une vue, tous les champs concernés disposent d'une liste déroulante permettant de sélectionner la relation adéquate. Parmi les options proposées, vous avez la possibilité de choisir "Ne pas utiliser de relation" (défaut). Voici un exemple avec une vue de type commentaire, qui par défaut ne propose aucun champ appartenant au groupe "Node", ni au groupe "Utilisateur" :
Une vue de type commentaire propose les relations "Commentaire : node" et "Commentaire : utilisateur". En sélectionnant "Commentaire: node", tous les champs du noeud auquel le commentaire est attaché sont disponibles. De plus tous les champs utilisateur liés à l'auteur de ce noeud sont également disponibles (via la relation cachée d'un noeud à son auteur). En sélectionnant "Commentaire : utilisateur", vous accédez aux champs liés à l'auteur du commentaire -- qui le plus souvent n'est pas l'auteur du noeud!
Dans cet exemple, si vous ajoutez le champ "Utilisateur : nom", l'interface vous propose alors le choix entre une relation de type "Node" ou une relation de type "Utilisateur". La relation "Node" permet comme vu précédemment d'accéder au nom de l'auteur du noeud, alors que relation "Utilisateur" vous permet d'accéder au nom de l'auteur du commentaire. L'une des deux relations doit obligatoirement être choisie pour permettre à Views de choisir quel utilisateur afficher.
La table "files", créée par le module "Upload", illustre un autre exemple de relations. Dans Drupal, les fichiers sont liés aux utilisateurs, mais pas toujours à des noeuds. Cependant, le module "upload" permet aux fichiers d'être attachés à des noeuds via la table "upload". Ceci permet à Views, en partant d'une vue 'Node', de proposer le champ 'fichier attaché'. Mais dans l'autre sens, en partant d'une vue 'File', il faut créer une relation via la table "upload" pour extraire les informations au sujet du noeud.