Bonjour,
Ces perspectives sont superbes, et je serai très content de disposer de ces
fonctionnalités bientôt.
Simplement, l'éventail est très vaste et mériterait une dénomination 2.0
Les réflexions concrètes que cela m'inspire, du point de vue du
"consommateur" que je suis : je ne peux malheureusement pas passer beaucoup
de temps à ces activités, et donc encore moins aux (nombreux) tests
nécessaires à la mise au point (et je pense que je ne suis pas le seul),
surtout si ces fonctionnalités sont si étendues :
Pourquoi ne pas essayer de stabiliser une version 1.8, sans ces
fonctionnalités (superbes) d'accès à d'autres tables, d'autres sites
(j'imagine que c'est un des endroits qui supposent de nombreux remaniements
du code actuel et tests, mais peut-être que la ligne de partage pourrait se
faire ailleurs) et de repousser à 2.0 les fonctionnalités plus avancées ?
Cela aurait plusieurs avantages, au niveau des utilisateurs, mais peut-être
même au niveau des développeurs et des testeurs :
- utilisateurs : disposer plus vite d'une version 1.8, qui sera testée aussi
plus vite assez largement
- développeurs et testeurs : avoir des points de repères supplémentaires,
qui complèteraient ceux qui existent déjà grâce aux fonctionnalités que je
pressens de "CVS". Un bug qui apparaît avec la "2.0 cvs" pourrait être
constaté ou non sur la "1.8 cvs", ce qui pourrait faciliter son débogage ?
Cela complexifie en apparence les développements, mais peut-être pas tant
que cela, et même peut-être cela apporterait des avantages significatifs ?
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 :
