Le 11 sept. 04, à 23:03, Jacques PYRAT a écrit :

> Sans tomber dans le vaporware à la m$, une idée de ce que vous les 
> dev, vous
> souhaiteriez/étidiez dans SPIP nous permettrais à nous, les 
> utilisateurs de
> savoir un peu mieux où nous allons.

Bon, alors voici ou va le dernier commit qui précède ce message.
C'est encore expérimental et sujet à révision mais ça semble 
fonctionner.

Il est à présent possible, non seulement de lire d'autres tables SQL 
que celles propres à Spip,
mais également d'aller lire des tables présentes sur d'autres serveurs, 
typiquement d'autres sites sous SPIP
mais pas seulement.

Pour ce faire, la syntaxe des types de boucles est étendue avec la 
notation suivante:

<BOUCLE_EXT(site-annexe:ARTICLES)>#TITRE</BOUCLE_EXT>
qui va lister tous les titres de la table article du serveur site-annexe

<BOUCLE_AUTREXEMPLE(site-pas-mal-non-plus:CATALOGUE)>
</BOUCLE_AUTREXEMPLE>
<br>#TOTAL_BOUCLE au catalogue
</B_AUTREXEMPLE>

qui va ramener le nombre d'entrées de la table CATALOGUE du server 
"site-pas-mal-non-plus".

Pour arriver à ce résultat il faut toutefois déclarer les nouveaux 
serveurs avec leur identifiant de connexion.
Chacun est déclaré dans un fichier portant son nom, préfixé par 
"inc_connect-" et suffixé par ".php3",
le fichier étant placé dans ecrire (donc ci-dessus, il faut 
ecrire/inc_connect-site-annexe.php3).
Ce fichier doit contenir 4 fonctions (où NOM est à nouveau le nom du 
serveur):

function spip_NOM_fetch($res, $serveur)  équivalente à spip_fetch_array 
(i.e. mysql_fetch_array)dans le serveur usuel
function spip_NOM_count($res, $serveur) équivalente à spip_num_rows 
(i.e. mysql_num_rows) dans le serveur usuel
function spip_NOM_free($res, $serveur) équivalente à spip_free_result 
(i.e. mysql_free_result) dans le serveur usuel
function spip_pgsql_select($select, $from, $where,
			   $groupby, $orderby, $limit,
			   $sousrequete, $cpt,
			   $table, $id, $serveur)
equivalente à spip_mysql_select dans le serveur actuel (i.e. 
mysql_query après un pré-traitement non négligeable).

Les 4 fonctions du serveur usuel figurent dans ecrire/inc_db_mysql.php3 
et il faut évidemment s'en inspirer
pour écrire les 4 nouvelles, ainsi que de inc-connect.php3 pour la 
gestion des identifiants de connexion.

Ce fichier sera lu à l'exécution de la première boucle référençant ce 
serveur, et ne sera plus lu par la suite;
on peut donc y placer l'ouverture de la connexion.

Si le site annexe est sous un Spip de meme numéro de version, cela doit 
suffire car la description des tables
dans le inc_serialbase du serveur principal servira à interroger celles 
du serveur distant.

En revanche, si l'on veut en plus accéder à des tables spécifiques, il 
faut les ajouter à la globale
$tables_principales, par exemple comme je le disais tout à l'heure 
ainsi:

$spip_title = array(
		"id"	=> "bigint(21) NOT NULL",
		"title"	=> "text NOT NULL"
);
$spip_title_key = array(
		"PRIMARY KEY"		=> "id"
);
$GLOBALS['tables_principales']['title']=
  array('field' => &$spip_title, 'key' => &$spip_title_key);

Comme il n'est pas question de placer cette affectation directement 
dans le fichier inc_serialbase
qui ne doit décrire que les tables locales d'une part, et qu'on ne peut 
indéfiniment charger mes_fonctions.php3
avec des déclarations qui ne sont pas systématiquement utiles, Spip 
procède à présent à la lecture d'un
fichier spécifique à chaque squelette: si le squellette s'appelle S, 
Spip lira le fichier S_fonctions.php3
avant chaque éxécution du squelette compilé (et juste avant sa 
compilation éventuelle).
On peut donc mettre dans ce fichier la description des tables comme 
ci-dessus, ainsi que les filtres spécifiques
au squelette si l'on veut soulager mes_fonctions.php3 (qui reste lu au 
départ néanmoins).

Ce qui ne marche pas encore :
-----------------------------

- les balises formulaires, parce qu'elles appellent des fonctions 
annexes qu'il faut reprendre une à une:
on ne peut donc faire apparaitre sous un site Spip le formulaire de la 
pétition déclarée sur un autre site;

- la seule requête gérée est SELECT, il n'est pas question d'alimenter 
le forum d'un site distant car cela nécessite
un UPDATE ou un INSERT; en contre-partie, il n'est pas nécessaire 
d'avoir le ALL PRIVILEGES sur la base lue,
un accès en lecture suffit;

- l'interface permet a priori d'interroger d'autres serveurs que MySQL; 
j'ai procédé à des essais avec postgres,
ça marche pour des boucles sans critères comme celles ci-dessus, mais 
le compilateur actuel traduit les critères
par des idiosyncrasies MySQL  qu'il faut retraduire au niveau de 
spip_postgres_select,  il y a encore du travail.

- le debugger de squelette aura peut-etre besoin d'etre debugé quant à 
sa gestion de ces nouveaux venus...

Bonne expérimentation à tous,

			Emmanuel