Oui, il faudrait redonner de la fiabilité à tests/ pour que ça devienne
1. Le test balises/expose.html est cassé suite aux récentes
modifications de la syntaxe des #INCLURE
=> indique une perte de compatibilité ascendante
2. Le test inclure_array.html est cassé (je ne sais pas ce qu'il vérifie)
3. _q() est cassé mais c'est pas grave puisque déprécié => j'élimine le test
4. j'ai corrigé filtres/abs_url.html
5. le sql_multi (sql/10_sql_insert_select.php) en MySQL est foireux,
mais le code est si compliqué que je ne sais pas comment le traiter
6. sql/40_sql_divers.php couine sur 1/2 qui vaut 0.5 en MySQL, au lieu
de 0 comme attendu. Il faut sans doute éviter de se reposer sur ce
genre de calculs si on veut être multibase... et du coup éliminer ce
test
Je ne comprends rien à la manière dont c'est rédigé, parce qu'une fois de plus on s'appuie sur l'état de l'implémentation du phraseur au lieu de s'en tenir aux specs. Je ne sais PAS interpréter:
trim porte sur quelle balise ? #INCLURE ou #GET ? Avec de la mauvaise volonté je pourrais même dire #SET voir #DOSSIER_SQUELETTE. Il FAUT mettre des parenthèses autour des filtres.
Je ne comprends pas pourquoi le jeu de tests a été écrit de manière compliquée: il râle à propos de #EXPOSE, mais c'est probablement #INCLURE qui est en cause, et un autre jour ce sera #SET ou #GET.
Je n'ai pas réfléchi à la question, mais je serais quand même surpris qu'on ne puisse pas faire autrement.
1. Le test balises/expose.html est cassé suite aux récentes
modifications de la syntaxe des #INCLURE
=> indique une perte de compatibilité ascendante
Je ne comprends rien à la manière dont c'est rédigé, parce qu'une fois de plus on s'appuie sur l'état de l'implémentation du phraseur au lieu de s'en tenir aux specs.
Ces specs existent quelque part ?
Car en leur absence, force est de constater que c'est bien l'état de l'implémentation qui fait foi, au jeu toujours gagnant des essais-erreurs pour trouver la syntaxe qui ne fait pas planter le phraseur tout en produisant le code compilé attendu.
trim porte sur quelle balise ? #INCLURE ou #GET ? Avec de la mauvaise volonté je pourrais même dire #SET voir #DOSSIER_SQUELETTE. Il FAUT mettre des parenthèses autour des filtres.
Certes, c'est devenu la règle stricte.
Mais jusqu'ici c'etait des fois [()] qui marchait, des fois rien, des fois des uniques (), selon la place dans l'expression.
Je veux bien qu'on dénonce les écritures déviantes face aux specs, mais ces écritures sont les seules qu'on arrivait à faire passer.
En l'absence de ces specs écrites, on est bien en peine de dénoncer un bug, et on s'adapte donc à ce qu'accepte de manger le phraseur.
Je ne comprends rien à la manière dont c'est rédigé, parce qu'une fois de plus on s'appuie sur l'état de l'implémentation du phraseur au lieu de s'en tenir aux specs. Je ne sais PAS interpréter:
trim porte sur quelle balise ? #INCLURE ou #GET ? Avec de la mauvaise volonté je pourrais même dire #SET voir #DOSSIER_SQUELETTE. Il FAUT mettre des parenthèses autour des filtres.
Mais ? la parenthèse de concat lève toute ambiguité !
FAUX. L'écriture avec parenthèses marche TOUJOURS, et je n'ai pas raté une occasion de dire qu'il ne fallait PAS compter sur des licences d'un analyseur que je regrette de n'avoir pas refait form scratch depuis le début.
J'attends toujours la réponse sur recuperer_fond, car si en plus il y a un bug à corriger qui impacte sur EXPOSE, j'aimerais avoir toutes les infos autour de ça, et ne pas avoir à demander 10 milles fois une information qui aurait dû figurer qq part: les commentaires, les messages de log ou la doc, c'est pas les lieux qui manquent.
Tu es la 2e personne à dire qu'il y a des parenthèses alors qu'il n'y en a pas une seule dans cette écriture. Pour qu'il y ait filtre, il faut qu'il y ait parenhèses, je considère cette écriture comme incorrecte, et partant ambigue dans son intention.
Maintenant, un ordinateur étant une machine déterministe, la notion d'ambigutié lui est inconnue et quand on connait le programme qu'elle déroule, par exemple quand on l'a écrit soi-même, on peut prévoir à coup sûr ce qu'elle va faire. Je sais tout ça, merci. Mais ce n'est pas la question.
Tu es la 2e personne à dire qu'il y a des parenthèses
Non ce n'est pas ce que j'ai dit. Tu aimes bien être précis pourtant.
Pour qu'il y ait filtre, il faut qu'il y
ait parenhèses, je considère cette écriture comme incorrecte, et partant
ambigue dans son intention.
Je suis d'accord mais il s'agit bien d'un exemple de choses usitées,
donc à risque si on les casse. Mérite à minima de grepper toute la
zone pour voir si c'est répandu.
Puisqu'on est dans les tests unitaires, je viens de me relancer les quelques tests que j'avais codé avec SimpleTest (avec SPIP 2.0) sur une 2.1 et j'ai quelques surprises de changements…
Le plus marquant semble être que <BOUCLE_meta(META){nom=nom_site}>#VALEUR</BOUCLE_meta> ne fonctionne plus.
Ironie du sort, je me sers de cette boucle plein de fois dans les tests !
Un autre changement (en bien) est que ces tests renvoient maintenant tous "", les 3 derniers devenant donc faux en 2.1 :
function testBaliseInexistante(){
$this->assertEqualCode('','#JENEXISTEPAS');
$this->assertEqualCode('','[(#JENEXISTEPAS)]');
$this->assertEqualCode('','[avant(#JENEXISTEPAS)apres]');
// ceux-ci sont plus etonnant mais c'est ce qui se passe effectivement
$this->assertEqualCode('{rien}','#JENEXISTEPAS{rien}');
$this->assertEqualCode('{rien}','[(#JENEXISTEPAS{rien})]');
$this->assertEqualCode('avant{rien}apres','[avant(#JENEXISTEPAS{rien})apres]');
}
Ca, c'est suite à l'échange avec cy_altern: il y a des serveurs SQL où la différence majusucles / minuscules joue, ce qui empêche d'appliquer le compilateur de squelettes dessus.
Idéalement, on devrait dire qu'à partir de maintenant le compilateur ne convertit plus en minuscles le nom des tables, pour une nouvel arrivant à SPIP, ce serait le plus simple à comprendre. Comme néanmoins ça casserait beaucoup de choses, on a transigé en convertissant ce qui est listé dans $table_des_tables, qui était déjà un repère à cas particuliers. Pour les autres, il faut écrire en minuscules.
Ah ok, donc «meta» et pas «spip_meta» ni «META»… Ce que j'aimais bien entre majuscule / minuscule, du moins ce que j'en croyais, c'est que le premier est un alias alors que le second est le vrai nom. Il semble que ce n'était pas totalement cette distinction qui était faite.
J'ai juste peur là que la distinction alias / vrai nom devienne moins évidente si tout est en miniscule.
oui, ça m'ennuie aussi, mais on n'a pas trouvé comme règle simple permettant d'appliquer un squelette sur n'importe quelle base en cassant le moins possible de choses.