ESJ nous a fait un topo sur les entrailles du compilateur. Technique et ardu, je ne reproduis pas ici l’ensemble de ses propos, surtout que ça repose sur un schéma au tableau !...
Une application pratique
Utiliser une boucle sur une table mysql crée par l’utilisateur
Il n’est pas nécessaire de paramétrer quoi que ce soit.
Exemple :
vous créez une table contacts, avec les champs id_contact, nom, prenom, adresse au moyen de phpmyadmin ;
Vous pouvez ensuite dans vos squelettes directement utiliser des :
<BOUCLES_mescontacts(CONTACTS){nom=toto}>
#ID_CONTACT : #NOM : #PRENOM <br/>
</BOUCLES_mescontacts>Cela marche parce que SPIP, ne connaisant pas la table contacts par défaut, va rechercher dans votre base mysql si elle existe. La trouvant, il va s’en servir, et associer automatiquement les balises #ID_CONTACT, #NOM, #PRENOM aux champs respectifs id_contact, nom, prenom.
Attention : l’utilisation de nom de champs majuscules peut poser des petits problèmes de compréhension par le compilateur. Il est donc prudent d’utiliser des noms de champs en minuscule.
Les Critères
Comme vu ci-dessus, les critères correspondant au nom des champs sont automatiquement supportés. Toutefois vous pouvez définir des critères personalisés pour répondre à d’autres besoins.
Ceci se fait au moyen d’une fonction critere_xxx avec xxx le nom du critère
Exemple du critère origine_traduction :
// {origine_traduction}
// http://www.spip.net/@origine_traduction
function critere_origine_traduction_dist($idb, &$boucles, $crit) {
$boucle = &$boucles[$idb];
$boucle->where[] = $boucle->id_table.".id_trad = "
. $boucle->id_table . '.' . $boucle->primary;
}Ce critère permet de rechercher les articles dont id_trad correspond à l’id_article du contexte de la boucle.
Pour cela, il rajoute une condition where a la requete sql qui sera génrée par la boucle, ceci se fait en ajoutant un élément au tableau $boucle->where :
$boucle->id_table.".id_trad = ". $boucle->id_table . ’.’ . $boucle->primary ;
$boucle->id_table : le nom de la table
$boucle->primary : la clé primaire de la table, id_article ici
Et hop emballé c’est pesé !
Bonus !
Et même, _fil_ a ajouté une « feature » en live :
function critere_origine_traduction_dist($idb, &$boucles, $crit) {
$where = $boucle->id_table.".id_trad = "
. $boucle->id_table . '.' . $boucle->primary;
if ($crit->not)
$where = "NOT($where)";
$boucle->where[] = $where;
}Pour supporter la syntaxe !id_trad
Voyez comme ça valait pas le coup de s’en priver !
Vos commentaires
# Le 4 mars 2006 à 22:29, par cent21
En réponse à : SPIP 1.9 - Le Compilateur
Si j’ai bien compris, ça veut dire que l’on peut créer ses propres tables, manuellement ou automatiquement, et les intérroger dans le squelette avec des boucles spip, c’est bien ça ?
Parce que si c’est ça, il ne manque plus que le processus inversé (celui qui remplit les tables) et spip devient en plus une application de gestion (ecriture / lecture) de base de donnée MySql dans un langage proche du language naturel.
Mais même sans le processus inversé, je vois déjà plusieurs applications intéressante ...
1. La possibilité d’intérroger les pages du spikini, directement depuis spip ... Et plus largement, on peut intérroger n’importe quelle donnée de la BDD, y compris d’une application externe.
2. La possibilité d’extraire des donnés non prévue pour être extraite (heureusement que les mots de passe sont cryptés dans la BDD, car cela représenterait un risque de sécurité certain. D’ailleurs, rassurez moi, les mots de passe sont bien cryptés dans la BDD ?)
# Le 28 mars 2006 à 18:10, par Loiseau2nuit
En réponse à : SPIP 1.9 - Le Compilateur
Hey hey :-D
Alors si j’ai bien tout compris de ce que je viens de lire, moi ce que je vois là dedans, c’est peut être la solution à mon problème :
Est-il possible sur le même principe qu’expliqué dans l’article, d’écrire des boucles interrogeant une autre base de données issue d’une application externe et de lier les résultats obtenus à des articles de SPIP ?
Exemple purement fortuit :
- je crée un article « liste de cources » (qui en toute logique ira se caller dans la DB « spip ») auquel je lie un à un (genre en doc attaché ou en syndic, enfin bref...) tous les produits que je dois acheter en allant les chercher dans la DB « supermarché » qui a l’origine est attachée à une application web de gestion d’inventaire, par exemple...
Je ne sais pas si je suis très clair là...
(au passage, si ma question connais une réponse valable pour la version 1.8.3 je suis preneur, parce que j’ai déjà patché à bloc mon spip avec des contribs qui pour certaines modifient profondément mon noyau. J’avoue que je n’envisageait pas forcément de devoir upgrader mon spip si rapidement :/
# Le 24 avril 2006 à 14:58, par Déesse A.
En réponse à : SPIP 1.9 - Le Compilateur
Oui c’est possible, bien que pas documenté car l’interface peut encore changer.
Ecrire <BOUCLE1(serveur :table)...> au lieu de seulement <BOUCLE(table)...> comme habituellement va en effet utiliser la table du serveur explicitement désigné. Pour accéder à ce serveur, il faut ecrire un clone du fichier base/db_myslq.php,
qui concrétise les fonctions abstraites du fichier base/abstract_sql.php. Si le 2e serveur est un serveur MySQL c’est trivial, et il ne reste plus qu’à ouvrir la connexion à ce serveur, ce qui est le role du fichier inc_connect-serveur.php qui sera exécuté automatiquement par base/abstract_sql.php.
# Le 5 juin 2006 à 13:16, par Loiseau2nuit
En réponse à : SPIP 1.9 - Le Compilateur
Ca c’est génial :D
Dommage qu’il n’y ait pas un minimum de doc sur la question. Quelqu’un a t’il déjà une piste de recherche à me soumettre sur ce sujet svp ?
Zzz. ;)
# Le 7 juillet 2006 à 10:32, par yannick069
En réponse à : SPIP 1.9 - Le Compilateur
Bonjour,
Est-ce que cela fonctionne lorsqu’on ajoute des champs à une table existante ?
J’ai par exemple, ajouter le champ « avatar » à la table spip_auteur afin de pouvoir mémoriser un avatar pour chaque auteur.
L’appel de la balise #AVATAR dans une boucle ne me renvoie rien, alors que le champ est bien rempli dans la base de données.
Une idée ?
Merci par avance
Yannick
# Le 7 juillet 2006 à 11:52, par yannick069
En réponse à : SPIP 1.9 - Le Compilateur
Après quelques recherches, et surtout grâce à l’aide de la liste de diffusion, j’ai trouvé comment il fallait s’y prendre. Je poste ici pour ceux que ça intéresse :
Le compilo SPIP 1.9 intègre les champs des nouvelles tables, mais sur les tables existantes, il faut les spécifier, comme en 1.8.
- En 1.9, il suffit de créer un répertoire plugins/avatar avec un plugin.xml minimal dedans et un fichier avatar.php contenant ça :
include_spip('base/serial');
$GLOBALS['tables_principales']['spip_auteurs']['field']=
array_merge($GLOBALS['tables_principales']['spip_auteurs']['field'],
array(
'avatar' => "....",
)
);
- Il faut ensuite que le plugin.xml contienne une ligne
<fonctions>avatar.php</fonctions>- Enfin il faut activer ce plugin depuis l’interface d’admin
# Le 19 décembre 2006 à 00:09, par Loiseau2nuit
En réponse à : SPIP 1.9 - Le Compilateur
Ben... là je saisis pas l’intérêt... Spip ne le gère pas déjà ça, les avatars ? [(#LOGO_AUTEUR)]
# Le 26 février 2007 à 14:57, par ?
En réponse à : SPIP 1.9 - Le Compilateur
Bonjour tous...
Pour ma part, l’utilisation des BDs « rajoutées » ne fonctionnent pas : à chaque affichage, il m’affiche #MonChamp sans remplacer la valeur...
Une idée ?
Merci
Répondre à ce message
# Le 19 octobre 2006 à 21:59, par JVO
En réponse à : SPIP 1.9 - Le Compilateur
Ce système est absolument terrible, je craignais d’être obligé de rentrer dans les entrailles de SPIP mais cela se fait vraiment en un rien de temps.
Bravo !
Répondre à ce message