Petit rappel sur SPIP
Depuis la version 1.9 de SPIP il est possible d’accéder avec des boucles SPIP à des tables non SPIP. [1]
Cette possibilité trop méconnue offre des grandes possibilités. SPIP peut devenir le moteur de mise en page de nombreuses applications.
Ces tables externes, quelles sont elles ?
Je vois au moins deux utilisations principales à l’accès aux tables extérieures :
Interroger une application extérieure
Soit pour interroger des tables venant d’une application extérieure pré-existant, dont on veut accéder au contenu à partir d’un squelette SPIP. On peut par exemple utiliser les tables MySQL de n’importe quel script de forum à partir d’un squelette SPIP, pour afficher les derniers messages du forum quelque part à l’intérieur de ce squelette. On pourrait également redéfinir complètement le forum en SPIP et abandonner le script existant...
Interroger des tables que l’on crée
Soit pour interroger des tables créées sur mesure adaptées à un contextes donné, pour lesquelles on veut des champs différents de ceux proposés en standard par SPIP. A la place de surtitre, titre, soustitre, chapo et texte, par exemple, on peut préférer une table « POMMES » proposant les champs : « variete », « couleur », « gout », « origine », « date_degustation » et « indications ».
Par exemple
variete = Belle Fille de Salin
couleur = rouge-jaune
gout = parfum d’amande amère
origine = jura
date_degustation = novembre 2006
indications = à croquer, en jus ou à cuire. N’est pas sensible au gel.
(Saviez vous qu’en 1900, il existait plus de mille variétés de pommes en France ?)
On peut ainsi créer des applications entières utilisant SPIP comme moteur d’affichage.
Certains plugins qui créent leurs propres tables, avec des données extraites dans les squelettes, sont des exemples de mise en oeuvre.
Contraintes
Le traitement entièrement automatique ne requière aucune formalité préalable de la part du créateur de squelette. SPIP a en effet acquis la capacité à découvrir lui-même les particularités de ces tables qui lui sont inconnues et de travailler avec elles.
Il y a quelques contraintes à respecter pour que SPIP interroge les tables inconnues qui lui sont proposées :
Le nom des tables doit être entièrement en minuscule.
Donc pour l’exemple précédent la table « Pommes »devra être renommée « pommes ».
Ces tables doivent être situées dans la même base de donnée que les tables SPIP. Il est également possible de boucler sur des tables situées dans une autre base de donnée,, et même sur un autre serveur SQL, au prix d’un formalisme spécial et, pour SPIP1.9.2x au prix d’une pré-déclaration en PHP du nom, de l’adresse et du mot de passe de la base. [2]
euh... c’est tout ?
Pour l’instant, oui. Il y a d’autres contraintes mais c’est sur les jointures.
Interroger directement une table
Il est possible d’interroger une table externe directement via un classique boucle SPIP.
On bénéficie alors à l’intérieur de la boucle
des critères de tris sur tous les champs
des critères standards par hasard, inverse, etc...
de l’accés à tous les champs de la table
Exemple :
<ul>
<BOUCLE_mapomme(POMMES){par date_degustation}{inverse}>
<li>Le #DATE_DEGUSTATION, la #VARIETE a été dégustée</li>
</BOUCLE_mapomme>
</ul>doublons : dans la 1.9.2 on ne peut pas utiliser le critère {doublons}.
A partir de la version 1.9.3., il sera possible d’utiliser le critère {doublons} sur des tables dont un champ sera de type PRIMARY KEY. (A défaut, spip dénonce l’absence d’index sur la table).
Interroger directement deux tables avec jointure
Parfois on a besoin de joindre deux tables pour faire le lien entre leurs éléments. C’est ce qu’on appelle une jointure [3].
Par exemple, j’ai une table « pomme » et une table « gardiens » qui référencent les propriétaires de vergers qui se sont engagés à préserver certaines variétés rustiques de pommes. (C’est un peu ce que promeut l’association Kokopelli, pour la sauvegarde de la diversité potagère).
Cette table contient les champs « nom », « prenom », « adresse », « codepostal » « ville », « telephone », « variete », « quantite ».
Cette table contient des informations du genre Paul Lafarge, habitant La Petite Corcellie, 71190 La Chapelle, dispose de 10 pommiers de variété « Belle Fille de Salin »
C’est le champ « variete » qui fait le lien entre les 2 tables.
<BOUCLE_trouve(pommes gardiens){variete}>
La pomme #VARIETE est gardée par #NOM #PRENOM
</BOUCLE_trouve>Cas de plus de deux jointures
A noter que ce qui est valable pour 2 tables l’est également pour 3 ou plus. SPIP fait les jointures automatiquement.
Petite complication : à partir de 3 tables de jointures, l’ordre des tables est important et le résultat dépendra de l’ordre. Donc faire des essais sur l’ordre jusqu’à ce que le résultat escompté s’affiche. ( Si quelqu’un sait ou découvre quelle règle doit présider au choix de l’ordre des tables dans la boucle, qu’il le dise ! )
Cela permet de faire des tas de choses.
Noms complets et noms résumés
Lorsqu’une table, même externe a le même préfixe qu’une table SPIP, alors il est possible de la référencer sans le préfixe à l’intérieur d’une boucle. On écrira alors son nom en majuscules, sans le préfixe : c’est son nom « logique » tandis que le nom en minuscule et avec le préfixe, c’est le nom « physique ».
Par défaut, le préfixe est « spip_ ». Dans une telle configuration, si on a dans la base de donnee une table « spip_mesfruits » on pourra la référencer directement avec « MESFRUITS » dans une boucle, exemple :
<BOUCLE_ext(MESFRUITS)>...</BOUCLE_ext>
( et dans une jointure idem. )
utilisation de la variable $table_des_tables :
Cette variable sert à SPIP pour le nom des boucles.
Si la table "spip_toto" n’est pas déclarée avec $table_des_tables[’toto’]=’toto’ ; alors il sera impossible de faire <boucle_bb(TOTO) >, mais seulement <boucle_bb(SPIP_TOTO) >, ou <boucle_(spip_toto) >, comme expliqué précédemment, ce qui a l’inconvénient d’être dépendant du préfix de table de SPIP.
En le déclarant, SPIP gère donc le préfixe de table dans les noms des boucles, ce qui permet des
Plugins en rapport
Voir aussi :
le plugin TableData qui permet de visualiser et modifier dans la partie privée les champs de n’importe quelle table non SPIP.
En faire plus
On peut aussi en vouloir plus de SPIP, et décider d’aller plus loin. Pour cela, on peut utiliser un protocole de déclaration de bases de données externes, de tables externes et de jointures.
Cela permet par exemple d’intégrer les tables externes aux sauvegardes de la base de donnée réalisées par SPIP [4] , ou cela permet de définir des jointures complexes. Attention ces formalismes ne sont pas parfaitement stabilisés, et en les utilisant on s’expose à refaire une partie du boulot lors d’une prochaine évolution de SPIP.
$table_des_jointures :
Sert à SPIP pour relier automatiquement 2 tables, ce qui fait que si on fait une boucle <boucle_bb(TABLE1)>#CHAMP_TABLE_2</boucle_bb>, SPIP fera automatiquement la liaison entre les 2 tables, à condition évidemment qu’elles aient une colonne de nom identique, par exemple "id_rubrique" toutes les deux.
Voir par exemple cette page du Carnet : MultiBase
RSS 2.0