Lorsqu'un symbole d'avant-boucle n'avait pas son chevron fermant,
le compilateur signalait bien l'erreur mais produisait quand même du code PHP,
leque étant syntaxiquement faux produisait une erreur PHP.
Bonne stratégie: poursuivre la compilation un caractère après le chevron ouvrant de cette avant-boucle pour traquer les éventuelles erreurs plus loi.
Ça marchait pour les critères sans arguments ou avec un seul argument.
La raison ? Non-factorisation et doublonnage de code : actuellement, les critères mêmes persos (pas juste les trucs SQL) qui ont 0 ou 1 arguments, ne passent PAS par le même code que ceux avec 2 ou plus. Alors qu'ensuite le traitement et la regex associée sont quasiment les mêmes… mais pas tout à fait, puisque dans le cas 2 ou plus ça ne cherchait pas le "?".
Pour l'instant on corrige juste le bug, mais il faudrait nettoyer le code et factoriser pour ne plus générer d'erreur de ce genre…
Au passage, pour SPIP 3.0, on backport la correction du "_" manquant qui faisait, là aussi qu'avec 2 arguments ou plus, on avait pas le droit d'avoir des critères avec_plusieurs_mots, alors qu'on peut avec 0 ou 1 argument. Même raison : code fait deux fois différemment, dont la regex.
avec des slash plutot qu'avec des . ; c'est plus coherent avec l'existant,
et plus proche de xpath.
{{{
<h1>yql youtube.search</h1>
<BOUCLE_youtube(DATA){datasource select * from youtube.search(150) where query='spip', yql}
{datapath /query/results/video}
{pagination 5}
{thumbnails/thumbnail/0/content == 'MD'}
>
<dt>
<a href="#URL"><img src="#VALEUR{thumbnails/thumbnail/0/content}" /></a></dt>
<dd><a href="#VALEUR{url}">#VALEUR{title}</a></dd>
</BOUCLE_youtube>
#PAGINATION
<p>#TOTAL_BOUCLE / #GRAND_TOTAL</p>
</B_youtube>
}}}
a noter dans l'exemple ci-dessus : {{{ #URL }}} et {{{ #VALEUR{url} }}} sont
tous les deux bien renseignes : la description de l'iterateur indique "*"
pour signaler que tout peut y etre transforme en balise.
Je profite de cette écriture massive pour normaliser quelque chose de trompeur lorsqu'on compare deux versions, savoir l'usage de " ou ' dans le premier argument de define et defined. Comme les chaînes entre apostrophes sont plus rapidement analysées que celles entre guillemets, je choisis l'apostrophe.
Dépot obtenu avec le script Shell:
{{{
a=$(find . -name "*.php" |grep -v extensions/ | grep -v /config/ | grep -v index.php | grep -v public.php | grep -v prive.php )
echo -n "Fichiers: "
echo $a|wc -w
for i in $a
do
sed -f ~/Sites/spip/spip.sed $i > /tmp/f.php
if diff -q $i /tmp/f.php
then
:
else
diff $i /tmp/f.php
# echo $i; php /tmp/f.php
# mv /tmp/f.php $i
fi
done
}}}
et le script Sed:
{{{
s/Copyright (c) 2001-20../Copyright (c) 2001-2011/
s,\(if [(]!*\)*\(defined* *[(]\)"\([^"]*\)"\(.*\);[[:space:]]*[#/]*.*$,\1\2'\3'\4;,
}}}
Dans ce dépot, le phraseur propage de telles erreurs en écrivant "false" dans le champs {{{param}}} des n½uds de l'arbre de syntaxe abstraite, et les fonctions de production de code se blindent face à cette situation mais ne la propagent pas encore elles-mêmes: il faut faire du cas par cas pour produire le maximum de code valide possible.
Application au débusqueur, qui accepte à présent que son premier argument soit autre chose qu'une chaîne (fournie par un appel à _T), savoir un tableau considéré comme les deux premiers arguments de _T, que le débusqueur peut ainsi appeler avec un style identique pour tous ses messages.
* un filtre inconnu est dénoncé à la compilation, c'est mieux qu'à l'exécution;
* centralisation des erreurs sur critère afin que la fonction principale du compilateur puisse en être informée.
Dans la mesure du possible, les extensions de SPIP définissant des critères ne devraient plus appeler directement {{{erreur_squelette}}}, mais retourner le tableau de ses deux arguments, afin que la fonction d'aiguillage de compilation de critères propage l'information.
Pour plus de sûreté, je remplace {{{a=b}}} par {{{!strcasecmp(a,b)}}} dans les endroits sensibles: normalement c'est inutile, mais c'est un exemple de ce qu'il faudra faire pour les cas où on comptait sur le passage en minuscules qui n'aurait pas dû être étendues aux autres tables que les standards lors de l'arrivée du nouveau compilateur de SPIP 1.8 (mea culpa).
L'inclusion accepte à la fois un nom de fichier entre parenthèses et un argument {{{fond=}}}, redondance obscure qui ne définit d'ailleurs pas quoi faire si les deux sont présents, et complexifie sans raison la fonction associée dans le décompilateur. En conséquence, on accepte à présent que le nom entre parenthèses ne se termine pas nécessairement par {{{.php}}}, auquel cas on considère qu'il s'agit du fond. Du coup la fonction de décompilation ne recoit plus que les 2 arguments évidents, savoir le nom de fichier et la liste des valeurs d'inclusions. Les anciens cas sont évidemment toujours acceptés, mais le décompilateur fournira la nouvelle syntaxe, sauf pour les inclusions calculées car on tombe sur une des limitations de l'analyseur actuel.
On peut donc écrire {{{<INCLURE(inc-pied)>}}} plutôt que {{{<INCLURE{fond=inc-pied}>}}}, mais il faut toujours écrire {{{<INCLURE{fond=#ENV{skel}}>}}}, ce qui est regrettable.
Le [http://zone.spip.org/trac/spip-zone/changeset/29950 plugin] permettant de réaliser plus facilement le devoir de vacances suite à la [http://videos.spip.org/spip.php?article113 session de Juin 2009 de SPIP-Party] devra être mis à jour (merci Mathieu).
En toute rigueur il faudrait vérifier des choses du genre {{{ a=, }}} à transformer en {{{ a="," }}} mais on suppose que la bonne écriture aura été utilisé spontanément bien que facultative.
denisb
Cerdic
RastaPopoulos
Matthieu Marcillaud
BennyB
Fil
Committo,Ergo:sum