Liminaire
Prérequis. Connaître le fonctionnement des boucles de SPIP et des critères de classement.
Compatibilité. La dernière version stable de SPIP (1.8.2.d) doit être installée : nous aurons en effet besoin du filtre parametre_url [1] introduit très récemment dans la distribution officielle (la version 1.8.2. ne suffit pas).
Objectif
Dans certains cas — assez rares [2] —, il est utile de permettre aux internautes de choisir eux-mêmes l’ordre d’affichage des données que vous leur proposez. L’exemple-type est celui des résultats d’une recherche interne au site où il est souvent intéressant de pouvoir trier les articles par pertinence, par date ou par date inverse. C’est cet exemple d’une page présentant les résultats d’une recherche que nous développons ici.
Pour le dire autrement — un petit dessin valant mieux qu’un long discours —, nous souhaitons arriver à quelque chose comme ceci : http://mag.spip.net/recherche.php?r... [3].
Le code
Venons-en tout de suite au fait. Voici le code que nous vous proposons d’ajouter dans votre squelette d’affichage des résultats d’une recherche. tel qu’écrit ci-dessous, ce code ne sera utilisable que dans ce cas bien précis (où un paramètre recherche est présent dans le contexte), mais il est facile de le modifier pour l’utiliser dans d’autres circonstances, ce qui pourra éventuellement faire l’objet d’un prolongement de cet article.
Quelques explications
Un usage intensif est fait de la balise #ENV [4], qui nous permet de récupérer la valeur d’un paramètre passé en url et de générer le tri adéquat en fonction de ce paramètre. Pratiquement, nous utilisons deux paramètres : tri et ordre. Combinés, ces deux paramètres devraient théoriquement nous permettre de générer dix cas de figure différents (chacun des cinq critères de tri utilisés ici pouvant être classés par ordre normal ou par ordre inverse). Nous avons cependant volontairement réduit ces possibilités à six, en estimant que le seul cas où un classement par ordre croissant des valeurs est pertinents est l’ordre chronologique (il n’est pas intéressant de trier une liste en commençant par le moins populaire, le moins visité ou le moins pertinent). Ceci n’étant qu’un exemple, il vous sera facile d’adapter le concept à vos propres besoins.
Nous utilisons abondamment les potentialités du filtres "?" , seule structure conditionnelle explicite du langage SPIP.
Le passage d’un mode de tri à un autre s’effectue grâce à une ligne de javascript dans le menu de type select qui est mis en place. Il est possible de remplacer ce menu par des simples liens html en supprimant les balises <select> ... </select> et en remplaçant simpement par <option value="..."> par <a href="..."> (et </option> par </a>).
Etant donné que nous utilisons la méthode « GET » pour transmettre les données de notre formulaire, une url différente est appelée pour chaque tri différent. Cela nous permet de ne pas avoir à nous soucier du cache de SPIP et au contraire d’en profiter pleinement. Un nouvel enregistrement dans le cache est en effet généré pour chaque url différent appelé.
Le filtre parametre_url permet de modifier l’url courant (#SELF) pour en modifier un des paramètres. Ceci nous évite de perturber d’autres fonctionnalités du site qui peuvent dépendre d’autres paramètres de l’url. Nous devons donc éviter de perturber ces autres paramètres comme nous le ferions en nous contentants de regénérer une url à partir des seuls paramètres utilisés dans le présent cadre.
Nous n’échappons pas à l’utilisation d’un peu de php, car il n’est actuellement pas possible de faire dépendre une boucle d’une structure conditionnelle et parce qu’il n’est pas encore possible de définir l’ordre du tri par une variable d’environnement. Des formules alambiquées utilisant des inclusions permettent dans certains cas de contourner le problème mais nous avons préféré privilégier la lisibilité du code.
Notez, dans les boucles d’affichage de la liste, la structure {par #ENV{tri},points}, qui utilise deux critères de tri sucessifs, ce qui n’est pas spécialement la méthode la plus intuitive. Elle est cependant inévitable car si nous avions écrit {par #ENV{tri,points}}, qui trie par points si tri n’est pas défini dans l’environnement — ce qui est a priori plus logique —, nous aurions butté sur une limitation du compilateur (points n’étant pas une donnée directement issue de la base de données, mais une pseudo-colonne, calculée par SPIP).
Pour l’affichage des informations relatives aux articles recherches (titre, introduction, métadonnées,...), nous faisons ici appel à un fichier inclus item.inc.php/html, ce qui évite de dupliquer ce morceau de code [5]. A toutes fins utiles, en voici le code :
Bien sûr, vous pouvez aisément remplacer cette inclusion par l’affichage des données normales attendues (#TITRE, #INTRODUCTION, #DATE,...)
Gestion des inclusions
Si vous jouez avec des inclusions [6] et surtout si le code proposé ici se trouve lui-même dans un fichier inclus, n’oubliez pas de faire passer les paramètres nécessaires aux squelettes inclus, de la façon suivante :
Concrètement, dans le cas présent, une inclusion prendra probablement la forme suivante :
Les paramètres transmis dans l’URL de la page seront alors passés dans le fichier inclus où ils pourront être utilisés.
Fichiers de langue
Avant de terminer, nous n’oublierons pas de compléter nos fichiers de langue [7] avec les chaînes utilisées, dont voici la version française :
Si votre site est monolingue et que vous ne souhaitez pas profiter de la centralisation des chaînes verbales qu’offre le module de gestion des langues, vous pouvez sans dommage vous passer de cette étape et remplacer les balises linguistique dans le code source que nous proposons par leur traduction.
Aller plus loin
Concernant la gestion de tris avancés, vous consulterez utilement l’article Définir le type de tri d’une rubrique avec des mots-clés.
L’article Trier les résultats d’une boucle par ordre alphabétique des auteurs examine le cas particulier (non pris en compte ici) du tri d’une liste d’articles par les noms des auteurs.
mise_a_jour
RSS 2.0