Hola,
Avec Christope, on a bosse sur les branches depuis quelques temps. On a proposé cette solution qui me parait bien, sauf pour le point soulevé par Antoine (voir ci dessous) Je serais d’avis de suivre cette contrainte (on n’est pas censé mettre des appels de fonctions PHP dans les requêtes générées par le squelette.) mais j’avais un problème technique avec inc-calcul-squel.php3 et je voulais pas passer 1 semaine a capter les 2000 lignes. Mais si quelqu’un me dit comment connaître la valeur de $id_rubrique dans le passage de cette conditionnelle, pas de problème, je veux bien m’en occuper.
Sinon, j’arrive pas à m’inscrire sur la liste spip-dev !
Merci, Michel.
-----Message d’origine-----
Hello,
Le truc, c'est qu'effectivement tu dois faire le calcul dans inc-calcul.
Si tu le fais dans inc-calcul-squel, la valeur récupérée (la liste des
sous-rubriques) sera valable à la date de compilation du squelette, pas de
calcul de la page elle-même (les squelettes ne sont recompilés que quand
le squelette source change). Jusque là c'est bon 
Pour faire ça sans passer par un appel de fonction, une solution est de
faire ce qui est dans un coin de la liste spip-dev, à savoir utiliser
une table auxiliaire qui stocke les infos de hiérarchie et permet de
les récupérer en ajoutant simplement une jointure (pas de récursion
sur l'arbre des rubriques). C'est pas simple, mais si jamais tu veux
t'y mettre, tu es le bienvenu.
a+
Antoine.
@ Antoine Pitrou <antoine@rezo.net> :
Pour faire ça sans passer par un appel de fonction, une solution est de
faire ce qui est dans un coin de la liste spip-dev, à savoir utiliser
une table auxiliaire qui stocke les infos de hiérarchie et permet de
Autre hypothèse : ajouter un champ 'hierarchie' à chaque rubrique, qui
contiendrait 1,7,98,120 si la rubrique 120 est fille de 98, elle-même fille
de 7 elle-même fille de 1 à la racine.
A mon avis y'a pas urgence, voyons cela après la 1.4...
-- Fil
Beurk: des informations redondantes dans une base de données? C'est pour
qu'elles aient une chance d'être fausses à un des endroits? 
Beurk: des informations redondantes dans une base de données? C'est pour
qu'elles aient une chance d'être fausses à un des endroits?
Y'en a d'autres : id_secteur
C'est vrai que quand tu entres des articles "à la main" dans la base, il
faut penser à appeler calculer_rubriques_actives() [enfin, un nom comme ça:
la fonction a changé de nom je ne sais plus quand] pour que les articles
soient pris en compte... Est-ce gênant ? Non.
-- Fil
Beurk: des informations redondantes dans une base de données? C'est pour
qu'elles aient une chance d'être fausses à un des endroits?
La redondance n'est pas à proscrire quand il s'agit d'éviter des calculs.
Par exemple les champs id_secteur sont déjà redondants, ainsi que le
champ statut dans la table rubriques. Tu remarqueras que tous ont trait
aux rubriques, parce que ce n'est pratique de travailler sur une relation
récursive avec SQL... En tout cas, MySQL ne permet pas d'optimiser ce
genre de trucs.