Bonjour
Dans la CVS de ce jour, mais cela se présentait déjà avant-hier, j'ai le forum à la racine d'un thread (squelette http://www.transactiv-exe.org/archiveforum.html) qui a une #DATE correcte, mais pas de #TITRE, #NOM ou #TEXTE.
La boucle suivante, dans ce quelette, donne les forums qui découlent de celui-ci et elle fonctionne correctement.
Sous la 1.7.2 tout fonctionne; sous la CVS, cela fonctionnait encore le 31/8, mais pas le 3/9, si je ne me trompe pas.
Cordialement
Yves Grenier
Dans la CVS de ce jour, mais cela se présentait déjà avant-hier, j'ai le
forum à la racine d'un thread (squelette
http://www.transactiv-exe.org/archiveforum.html) qui a une #DATE
correcte, mais pas de #TITRE, #NOM ou #TEXTE.La boucle suivante, dans ce quelette, donne les forums qui découlent de
celui-ci et elle fonctionne correctement.Sous la 1.7.2 tout fonctionne; sous la CVS, cela fonctionnait encore le
31/8, mais pas le 3/9, si je ne me trompe pas.
Je confirme le bug ; même problème que toi sur la CVS, alors que le problème
est absent en 1.7.2.
Ce qui est troublant (peut-être une piste pour tracer le bug), c'est que le
titre du pied du forum apparaît bien si on appelle
archiveforum.php3?id_forum=xxx où xxx est un message un peu profond dans la
discussion (ie, pas le pied du thread).
Cela dit, je n'ai pas trouvé
-- Fil
Dans la CVS de ce jour, mais cela se présentait déjà avant-hier, j'ai le
forum à la racine d'un thread (squelette
http://www.transactiv-exe.org/archiveforum.html) qui a une #DATE
correcte, mais pas de #TITRE, #NOM ou #TEXTE.Ce qui est troublant (peut-être une piste pour tracer le bug), c'est que le
titre du pied du forum apparaît bien si on appelle
archiveforum.php3?id_forum=xxx où xxx est un message un peu profond dans la
discussion (ie, pas le pied du thread).
Je suis dessus. si on supprime certaines boucles avant #TEXTE ça passe, c'est bizarre.
>>le forum à la racine d'un thread (squelette
>>http://www.transactiv-exe.org/archiveforum.html) qui a une #DATE
>>correcte, mais pas de #TITRE, #NOM ou #TEXTE.
Indépendamment du bug, qu'il va bien falloir comprendre et résoudre, tu vas
pouvoir simplifier ton squelette maintenant avec {id_thread} : pour
retrouver le pied de la discussion il suffit désormais de faire
<BOUCLE_pied(FORUMS){id_thread}>
Je suis dessus. si on supprime certaines boucles avant #TEXTE ça passe,
c'est bizarre.
On est dans la partie optionnelle APRES de la boucle
<BOUCLE_racine_forums_parents>, donc dans un contexte où l'ID_FORUM, le
TITRE etc sont définis depuis la <BOUCLE_forum_principal (FORUMS)
{id_forum}> ; mais la sélection envoyée par cette boucle est incomplète :
spip_abstract_select(
array("forum.id_article",
"forum.date_heure",
"forum.id_forum",
"forum.id_parent",
"forum.id_breve",
"forum.id_rubrique",
"forum.id_syndic"), # SELECT
Apparemment les champs requis par la partie <//B_racine_forums_parents> ne
sont pas remontés jusqu'à BOUCLE_forum_principal, et n'ont donc pas été
réservés : quand j'ai corrigé le "bug de la boucle récursive", j'ai fait
remonter cette réservation vers la boucle mère, mais ça ne suffit pas. On
est au plus profond du compilo, là, je passe un tour 
-- Fil
Fixé.
Emmanuel
Pas vraiment: je recopie plus mal mon propre code que toi, c'est tout !
Je signale que cette modif dans une partie auparavant stable est due au fait
que le code des balises est à présent une expression PHP, non plus un tableau
formé d'une expression et d'une suite d'instructions à assembler ensuite,
ce qui alourdissait et le compilateur et le compilé.
Ceux qui avaient commencé à écrire des balise avec l'API expérimentale de ma contrib
doivent donc très impérativement s'adapter à la nouvelle.
Emmanuel
Déesse A. wrote:
Bonjour
Dans la CVS de ce jour, mais cela se présentait déjà avant-hier, j'ai le forum à la racine d'un thread (squelette http://www.transactiv-exe.org/archiveforum.html) qui a une #DATE correcte, mais pas de #TITRE, #NOM ou #TEXTE.
Fixé.
Emmanuel
En effet, ça remarche!
Yves Grenier
Fil wrote:
le forum à la racine d'un thread (squelette
http://www.transactiv-exe.org/archiveforum.html) qui a une #DATE
correcte, mais pas de #TITRE, #NOM ou #TEXTE.Indépendamment du bug, qu'il va bien falloir comprendre et résoudre, tu vas
pouvoir simplifier ton squelette maintenant avec {id_thread} : pour
retrouver le pied de la discussion il suffit désormais de faire
<BOUCLE_pied(FORUMS){id_thread}>
Super! Je suis content de pouvoir simplifier ce squelette qui était un peu lourd!
Merci pour l'arrivée de ce {id_thread}.
Cordialement
Yves Grenier
Déesse A. wrote:
On
est au plus profond du compilo, là, je passe un tourPas vraiment: je recopie plus mal mon propre code que toi, c'est tout !
Je signale que cette modif dans une partie auparavant stable est due au fait
que le code des balises est à présent une expression PHP, non plus un tableau
formé d'une expression et d'une suite d'instructions à assembler ensuite,
ce qui alourdissait et le compilateur et le compilé.
Ceux qui avaient commencé à écrire des balise avec l'API expérimentale de ma contrib
doivent donc très impérativement s'adapter à la nouvelle.Emmanuel
Bonjour,
La nouvelle API est-elle décrite quelque part? Ou bien cela se limite-t'il pour le moment à la lecture des commentaires dans inc-balises.php3 complétée par la lecture de inc-compilo-index.php3 et inc-forum.php3?
Cordialement
Yves Grenier
La nouvelle API est-elle décrite quelque part? Ou bien cela se
limite-t'il pour le moment à la lecture des commentaires dans
inc-balises.php3 complétée par la lecture de inc-compilo-index.php3 et
inc-forum.php3?
C'est décrit dans le code uniquement, et ce sera susceptible de changements
tant qu'on n'a pas publié de version "officielle". Cela dit, si personne
n'expérimente, on n'aura pas assez de recul pour éventuellement faire les
changements qui s'imposeraient.
D'où l'alternative :
- personne ne teste, et c'est définitif (et définitivement foiré si
on s'est trompés)
- beaucoup de tests, et des changements à prévoir, mais pour de
bonnes raisons.
Je préfère la seconde option.
-- Fil
Il n'est pas très bon que les auteurs d'une application en rédigent le manuel:
ils laissent facilement beaucoup de non dits et manquent de recul par rapport
à la motivation personnelle qu'ils avaient en programmant cette application.
Il faudrait qu'un (ou plusieurs) correspondant de cette liste se dévoue à cette tâche,
avec des allers-retours avec les développeurs avant diffusion.
L'état actuel des choses me semble insatisfaisant sur les points suivants:
- je regrette d'avoir choisi le caractère "$" pour référencer une variable passée par URL,
car des squelettes incluant du PHP font cohabiter la même syntaxe pour désigner 2 variables
différentes (cf l'exemple de Fil: <?php $x=2 ?><BOUCLE1(ARTICLES){id_article=$x}> ...).
je crois que l'utilisation de "?" ou "&", qui évoquent la query-string, serait plus judicieux.
- la syntaxe du critère IN devrait comporter des parenthèses dans son 2e opérande,
pour garder la règle implicite qu'il n'y a qu'une seule entité après un opérateur,
et on pourrait alors y traiter les # et $ (ou son remplaçant) comme le souhaite à raison Paolo.
- le caractère # dans les critères me semble en revanche adéquat; son extension a n'importe qu'elle
balise, pas seulement un champ SQL, ne pose pb que pour une seule: #TOTAL_BOUCLE
(pour le coup, elle ne peut à la fois conditionner le nombre de passage dans la future boucle
et donner celui-ci d'avance). Mais on en est plus à une dérogation prês en ce qui la concerne.
- je suis très fana du debuger, mais il introduit un comportement nouveau en cas d'erreur,
l'utilisateur non prévenu ne distinguant pas un site à pb, d'un site dont les pages sont peu fournies
(et même prévenu on n'y pense pas toujours tout de suite).
Je serais pour qu'apparaisse le message "Site en travaux" lorsque cela arrive.
Emmanuel