dans le squelette cheznous, je n'avais encore jamais vu cette erreur,
que 2.1 fait apparaître :
Filtre rainette_afficher_unite non défini
plugins/cheznous/page_venir.html _article 17
-- Fil
c'est un filtre non exécuté qui ne provoquait pas d'erreur en 2.0, mais que le compilateur dénonce comme absent en 2.1
la syntaxe à utiliser dans ce cas est
appliquer_filtre{rainette_afficher_unite,...}
Ce qui permet de passer le compilateur et de ne vérifier l'existence du filtre qu'à l'execution éventuelle.
Cédric
Je suis étonné que cette erreur survienne étant donné que le code contenant le filtre est inclus dans un test de présence du plugin Rainette.
Ca serait plutôt du à des parenthèses et crochets manquant autour de la première balise #RAINETTE_INFOS ?
Non, non, c'est le compilo 2.1 : il dénonce les filtres inconnus présents dans le squelette *même* si ils ne sont jamais exécutes grâce à un test de présence comme ici.
Cédric
Euh ben pas dans tous les cas alors. j’ai un paquet de cas de ce type dans Sarka-SPIP, je suis étonné.
Mais si la partie incriminée tu l’as mets dans un include ça produit la même erreur ?
Non, pas si la partie inclue n'est inclue qu'en présence du bon plugin.
Dans ce cas, elle ne sera compilée que quand le filtre est là et ça passera.
Cédric
Ok, je pense que c’est la raison pour laquelle j’ai pas eu d’erreur jusqu’à présent. Mais je vais y veiller maintenant que je connais le souci.
Maintenant c’est vraiment une amélioration du compilateur ?
Oui parce que hormis le cas particulier cité ça dénonce une erreur, systématiquement et en amont, plutôt que d'attendre une exécution sur un jeu de données qui la fera apparaître. Ca amène une contrainte sur le cas particulier comme le tien, mais c'est une bonne discipline de programmation que de signaler explicitement qu'il y a un risque d'indéfini qu'on prend en connaissance de cause, d'autant que ça invite à réfléchir sur la raison de prendre un tel risque,
qui n'est souvent pas fondée et témoigne plutôt d'une mauvaise conception générale.
Committo,Ergo:Sum
Yo,
synthèse
situation de départ :
utilisation du filtre 'timestamp' du plugin 'spip_bonux'
si le plugin est activé.
si le plugin n'est pas activé,
les écritures 1, 2 et 3 ci-dessous produiront une erreur du débusqueur
("Filtre timestamp non défini").
l'INCLURE de l'écriture 4 étant conditionné à l'activation du plugin,
il ne sera pas effectué et le débusqueur ne lèvera pas d'erreur (et pour cause).
1- [(#VAL{rien.gif}|timestamp)]
2- [(#PLUGIN{spip_bonux}|oui) [(#VAL{rien.gif}|timestamp)]]
3- <INCLURE{fond=test, env}>
(avec le fichier 'test.html' qui contient l'écriture 1)
4- [(#PLUGIN{spip_bonux}|oui)
<INCLURE{fond=test, env}> ]
les écritures 1, 2 et 3 précédentes sont donc à remplacer par :
10- [(#VAL{rien.gif}|appliquer_filtre{timestamp})]
20- [(#PLUGIN{spip_bonux}|oui)
[(#VAL{rien.gif}|appliquer_filtre{timestamp})] ]
30- <INCLURE{fond=test, env}>
(avec le fichier 'test.html' qui contient l'écriture 10)
Wed, 17 Mar 2010 14:41:04 +0100, denisb:
1- [(#VAL{rien.gif}|timestamp)]
les écritures 1, 2 et 3 précédentes sont donc à remplacer par :
10- [(#VAL{rien.gif}|appliquer_filtre{timestamp})]
Ça c'est le genre de blague qui fait que plein de gens râlent sur la
complexité de SPIP et finissent par se barrer. Et encore, je dis ça
mais c'est pas moi qui me suis retrouvé devant ce cas, sinon je
serais encore plus abasourdi, et direct.
Attention à ne pas transformer le machin en usine à gaz, dont les
règles d'utilisation sont compréhensibles uniquement par ses
développeurs. S'il faut connaître la structure interne, qui
est complexe, de SPIP (ne seraient-ce que les différents niveaux de
génération de code, sur quoi opèrent le compilateur, le débuggueur,
etc.), pour pouvoir écrire des squelettes, les prérequis changent. À
la base, SPIP est censé simplifier le travail des webmasters pour
justement ne *pas* avoir à connaître tous ces rouages internes.
Il ne faut pas oublier ça. Là on part de l'envie de simplifier les
choses, et pour les simplifier on finit par arriver à des règles
excessivement complexes (<troll>cf. Perl, et peut-être PHP</troll>).
Mon but ici n'est pas de dire "c'est bien" ou "c'est mal". Juste, ça
fait un peu plus d'un an que je travaille avec SPIP, dans cette
année qui est passée vite je crois avoir appris plein de choses,
commencé à cerner les grandes lignes de son fonctionnement interne
même si je loupe encore plein de trucs (comme tout le monde à ce
stade), et franchement c'est le genre de subtilité qui me serait passé
complètement au-dessus au moment d'écrire un bête squelette. C'est pas
normal: signe d'un échec dans les objectifs.
Bonjour,
Dommage qu'il faille ainsi compliquer l'écriture, alors que cette situation n'a rien de particulière dans les squelettes (excuse-moi de te contredire, Committo,Ergo:Sum).
Peut-être qu'un log suffirait-il, à l'instar des fonctions en viellesdef ou des échos progressivement supprimés en partie privée ?
PHP lui-même ne bippe que si le filtre n'existe pas au moment de l'exécution...
Pat
+10000
Pat
* davux tapuscrivait, le 17/03/2010 15:24:
Wed, 17 Mar 2010 14:41:04 +0100, denisb:
1- [(#VAL{rien.gif}|timestamp)]
les écritures 1, 2 et 3 précédentes sont donc à remplacer par :
10- [(#VAL{rien.gif}|appliquer_filtre{timestamp})]
Ça c'est le genre de blague qui fait que plein de gens râlent sur la
complexité de SPIP et finissent par se barrer. Et encore, je dis ça
mais c'est pas moi qui me suis retrouvé devant ce cas, sinon je
serais encore plus abasourdi, et direct.Attention à ne pas transformer le machin en usine à gaz, dont les
règles d'utilisation sont compréhensibles uniquement par ses
développeurs. S'il faut connaître la structure interne, qui
est complexe, de SPIP (ne seraient-ce que les différents niveaux de
génération de code, sur quoi opèrent le compilateur, le débuggueur,
etc.), pour pouvoir écrire des squelettes, les prérequis changent.. À
la base, SPIP est censé simplifier le travail des webmasters pour
justement ne *pas* avoir à connaître tous ces rouages internes.
Il ne faut pas oublier ça. Là on part de l'envie de simplifier les
choses, et pour les simplifier on finit par arriver à des règles
excessivement complexes (<troll>cf. Perl, et peut-être PHP</troll>).Mon but ici n'est pas de dire "c'est bien" ou "c'est mal". Juste, ça
fait un peu plus d'un an que je travaille avec SPIP, dans cette
année qui est passée vite je crois avoir appris plein de choses,
commencé à cerner les grandes lignes de son fonctionnement interne
même si je loupe encore plein de trucs (comme tout le monde à ce
stade), et franchement c'est le genre de subtilité qui me serait passé
complètement au-dessus au moment d'écrire un bête squelette. C'est pas
normal: signe d'un échec dans les objectifs.
Le cas sur lequel nous glosons est un cas extrêmement rare qui, me semble-t'il, ne se produit *que* dans le cas du développement d'un squelette générique susceptible d'utiliser un plugin s'il est là, et de ne rien faire sinon.
Ce n'est pas le cas général où l'on crée un squelette qui ne servira que pour un site sur lequel tous les plugins utilisés par le squelette sont forcément installés.
Franchement, la balise #PLUGIN, elle ne sert que pour des squelettes génériques.
Et ceux qui développent de tels squelettes ont juste besoin de connaître la syntaxe qui va bien.
Pour les autres, la vérification de l'existence de tous les filtres à la compilation est une avancée utile pour la mise au point des squelettes.
-- RealET
On ne part pas d'une envie de simplifier les choses, on part du besoin de prévenir une erreur le plus tôt possible. C'est un mauvais plan d'estimer la qualité d'un système à la rapidité de rédaction qu'il offre, si cette rapidité se paye par des erreurs qu'on ne verra que tardivement, une fois le site en production. Un squelette qui produit des résultats différents selon un contexte non explicité dans l'environnement (ici qu'un plugin est actif ou pas) relève d'une mauvaise conception, repérable par le fait qu'on ne peut pas produire automatiquement le jeu de tests qui permettrait de vérifier les deux situations.
Le vrai reproche à faire ici est que SPIP n'a pas encore d'outil de génération de tests, mais c'est un autre sujet.
Committo,Ergo:Sum
Autre idée, ou manière d'exploiter ce log : une page dans la partie privée,
dédiée aux avertissements de compilation
avec des liens actifs vers les infos utiles (boucle, fichier, n° ligne)
comme le débusqueur sait si bien faire...
Page pour laquelle il y aurait plein d'autres usages je pense...
pour toute la subtilité qui existe entre "OK" et "Erreur Stop"...
PS : Ceci dit je suis d'accord avec le fait que ce pb spécifique
ne concerne presque PAS les webmasters, mais quasiment seulement
les concepteurs de squelettes à distribuer.
JLuc
Wed, 17 Mar 2010 15:54:21 +0100, Ergo:sum:
On ne part pas d'une envie de simplifier les choses, on part du
besoin de prévenir une erreur le plus tôt possible.
Ben, les deux, et l'un ne doit pas empêcher l'autre.
Pour reformuler ce que disait quelqu'un plus haut dans le fil:
prévenir est une chose, tout bloquer en est une autre. Peut-être
qu'un avertissement dans un coin sans pour autant se la jouer flic
zélé permettrait des "ah oui tiens, pas bête", tout en laissant le
dernier mot à la personne qui fait son squelette. (tiens ça rime)
prévenir est une chose, tout bloquer en est une autre. Peut-être
qu'un avertissement dans un coin sans pour autant se la jouer flic
zélé permettrait des "ah oui tiens, pas bête", tout en laissant le
dernier mot à la personne qui fait son squelette. (tiens ça rime)
En l'occurrence le message d'erreur n'apparaît que pour le webmestre.
à flic flic et demi
-- Fil
Ah ben quand même, je ne peux que m'insurger !
http://www.spip-contrib.net/TestBuilder
et la production de tests qui en a résulté, au moins sur
http://zone.spip.org/trac/spip-zone/log/core/tests
Ce n'est pas encore une usine à tests automatiques, mais les prémices sont là, pour ce qui est du PHP au moins, et ça permet surtout de générer très vite un test assez systématique et exhaustif sur une fonction qui existe déjà avant de la faire évoluer pour assurer sa non régression.
Cédric
Oui Cédric, mais je parlais de génération automatique de tests sur les squelettes,
pas de génération semi-automatique sur des fonctions isolées.
C'est ce que je fais déjà pour le validateur en boucle,
mais avec des approximations que j'aimerais pouvoir évacuer:
http://trac.rezo.net/trac/spip/browser/branches/spip-2.0/ecrire/exec/valider_xml.php#L215
Committo,Ergo:Sum