Bonjour,
Des petits soucis apparaissent en ce moment avec de débuggueur surpuissant de la 2.1 : il dit des erreurs tout à son honneur, mais lorsquelles sont prévues, c'est embêtant.
Ces deux exemples font boom (fonction absente).
[(#PLUGIN{toto}|oui)
[(#VAL|toto_ma_fonction)]
]
[(#SPIP_VERSION|<{2.1}|oui)
[(#VAL{text_area}|barre_typo{#LANGUE})]
]
Si les erreurs sont prévues, je ne comprends pas où est le pb. Peux-tu donner le mes_fonctions qui va avec tes exemples pour éclaircir la chose ?
Committo,Ergo:Sum
Justement, pas besoin.
Imagine un plugin «toto» qui crée un filtre «toto_ma_fonction». Rien de sorcier.
Lorsque le plugin est là, dans un squelette, tu peux appeler la fonction, ok.
Pour savoir si le plugin est là on teste souvent avec [(#PLUGIN{toto}|oui) … ]
[(#PLUGIN{toto}|oui)
[(#VAL|toto_ma_fonction)]
]
Donc, plugin non actif => il ne doit pas y avoir d’erreur qui apparaisse.
L’autre exemple est vrai aussi.
Bref, là, ma page poum.html contenant l’exemple ci-dessus, me génère :
Ah, bah voilà une belle discussion sur la sémantique de SPIP.
Un plugin est qqch qui peut définir plusieurs choses, en particulier des filtres, des critères et des balises.
Il est clair que dans le cas des critères et des balises, il faut avoir chargé le code du plugin si on veut pouvoir compiler un squelette qui va les utiliser. Pour les filtres, on peut ne pas l'imposer, mais:
1. c'est incohérent avec ce qu'on exige pour les critères et les balises;
2. ça oblige à produire un code compilé beaucoup plus lourd, car on doit produire le code qui produira (tu me suis ?) le message d'erreur si le filtre n'est toujours pas là à l'exécution, code qui de plus empêche potentiellement l'optimiseur d'opérer.
Il vaut donc mieux compiler avec le plugin chargé, ou alors utiliser le filtre chercher_filtre pour bien signifier que l'absence du fitre à la compil est assumée.
J'ai bien conscience qu'on casse la compatibilité ici, et on peut discuter de l'opportunité de se permettre ça pour la sortie d'une version mineure comme la 2.1. On peut revenir à la sémantique antérieure pour celle-ci, mais pour SPIP 3 au moins je pense qu'il faut passer à la nouvelle sémantique qui n'a que des avantages.
Committo,Ergo:Sum
Pour savoir si le plugin est là on teste souvent avec [(#PLUGIN{toto}|oui) … ]
[(#PLUGIN{toto}|oui)
[(#VAL|toto_ma_fonction)]
]Donc, plugin non actif => il ne doit pas y avoir d'erreur qui apparaisse.
Ah, bah voilà une belle discussion sur la sémantique de SPIP.
J'ai bien compris ton intention louable. Je signale simplement que là, on obtient des couacs auxquels on ne s'attend pas (en SPIP) – C aurait effectivement râlé de la même façon.
Il vaut donc mieux compiler avec le plugin chargé, ou alors utiliser le filtre chercher_filtre pour bien signifier que l'absence du fitre à la compil est assumée.
J'ai bien conscience qu'on casse la compatibilité ici, et on peut discuter de l'opportunité de se permettre ça pour la sortie d'une version mineure comme la 2.1. On peut revenir à la sémantique antérieure pour celle-ci, mais pour SPIP 3 au moins je pense qu'il faut passer à la nouvelle sémantique qui n'a que des avantages.
Et dans ces exemples, ça donnerait quoi, du coup, la nouvelle sémantique comme écriture ?
Pour savoir si le plugin est là on teste souvent avec [(#PLUGIN{toto}|oui) … ]
[(#PLUGIN{toto}|oui)
[(#VAL|toto_ma_fonction)]
]Donc, plugin non actif => il ne doit pas y avoir d'erreur qui apparaisse.
Ah, bah voilà une belle discussion sur la sémantique de SPIP.
Un plugin est qqch qui peut définir plusieurs choses, en particulier des filtres, des critères et des balises.
Il est clair que dans le cas des critères et des balises, il faut avoir chargé le code du plugin si on veut pouvoir compiler un squelette qui va les utiliser. Pour les filtres, on peut ne pas l'imposer, mais:1. c'est incohérent avec ce qu'on exige pour les critères et les balises;
- Les balises absentes produisent en principe un résultat vide qui est ignoré
- les boucles peuvent etre suivie d'un ? pour que le compilateur ne rale pas si la boucle n'est pas definie (cf le core sans le plugin forum).
La modif que tu as introduite va donc à l'envers de ces deux points, puisqu'il n'est plus possible d'ecrire un squelette qui marche sans un plugin mais fait des trucs en plus si le plugin est la (en utilisant un filtre du plugin).
Avant cette modif, le cas qui posait encore problème etait effectivement les critères.
On quelques cas typiques où il serait utile de pouvoir résoudre ce cas là.
2. ça oblige à produire un code compilé beaucoup plus lourd, car on doit produire le code qui produira (tu me suis ?) le message d'erreur si le filtre n'est toujours pas là à l'exécution, code qui de plus empêche potentiellement l'optimiseur d'opérer.
Il vaut donc mieux compiler avec le plugin chargé, ou alors utiliser le filtre chercher_filtre pour bien signifier que l'absence du fitre à la compil est assumée.
J'ai bien conscience qu'on casse la compatibilité ici, et on peut discuter de l'opportunité de se permettre ça pour la sortie d'une version mineure comme la 2.1. On peut revenir à la sémantique antérieure pour celle-ci, mais pour SPIP 3 au moins je pense qu'il faut passer à la nouvelle sémantique qui n'a que des avantages.
Du point de vue du compilateur, certes.
Du point de vue des utilisateurs c'est moins évident. Il ne faut pas les oublier.
Cédric
- Les balises absentes produisent en principe un résultat vide qui est ignoré
- les boucles peuvent etre suivie d'un ? pour que le compilateur ne rale pas si la boucle n'est pas definie (cf le core sans le plugin forum).La modif que tu as introduite va donc à l'envers de ces deux points,
...
Avant cette modif, le cas qui posait encore problème etait effectivement les critères.
C'est quelque peu biaisé de donner une conclusion sur la base de prémices incomplets, qu'on complète seulement après le verdict. Le "?" après les boucles est exactement le pendant du "chercher_filtre" que je signalais, les deux sémantiques ont donc le même nombre de contraintes dans le cas du plugin inactif. Dans le cas actif, la nouvelle est plus perfomante, que demande le peuple ?
Du point de vue du compilateur, certes.
Du point de vue des utilisateurs c'est moins évident. Il ne faut pas les oublier.
C'est absurde d'opposer le compilateur et les utilisateurs, alors que celui-ci a fait l'objet d'un travail d'amélioration dirigé vers eux. Avec la sémantique précédente, on pouvait avoir le scénario suivant:
1. un utilisateur compile un squelette comportant l'exemple de Mathieu reférensçant le filtre F du plugin P alors inactif.
2. il active le plugin P.
3. il demande une page utilisant le squelette en question: paf, erreur filtre F indéfini.
pour ma part, c'est ça que j'appelle "oublier les utilisateurs" car c'est incompréhensible.
Ce qu'on peut faire en revanche pour aider à l'abandon de cette sémantique incohérente, c'est que la balise #PLUGIN émette un avertissement si le plugin est inactif pendant la compilation.
Committo,Ergo:Sum
Non, les utilisateurs comprennent très bien qu'activer ou désactiver un plugin nécessite très souvent de vider les caches de SPIP. Le problème ne se situe pas ici je crois.
Il faut trouver des solutions pour qu'un squelette ait des parties optionnelles en fonction de la présence ou non de plugins. Un autre exemple est celui là :
[(#PLUGIN{toto}|oui)
[(#INCLURE{fond=inclure/toto})]
]
De la même manière qu'un filtre, une balise absente ou une inclusion peut être non trouvée. Le compilateur doit il alors aussi renvoyer des erreurs ? C'est pareil pour les critères (et là, comme eux ne sont pas débrayables, ça me pose effectivement, comme à Cédric ou Sarka des problèmes)
Exemple, le critère {tout_voir} de Accès Restreint, dès qu'on écrit ce critère sur une boucle, on rend le squelette dépendant de Accès Restreint, même s'il n'est pas actif, or, comme certains cherchent à proposer des jeux de squelettes assez génériques, on aimerait bien pouvoir indiquer, comme pour les boucles qu'un critère *peut* ne pas exister, et ça dans l'écriture de la boucle, pas en créant un faux critere_tout_voir() dans un mes_fonctions pour pas que SPIP râle (sarka) ou en recréant la fonction absente de SPIP 2.1 (fausse barre_typo() dans tickets ; beurk !).
Bref, améliorer le débuggueur est une chose, mais il faut trouver aussi des solutions aux problèmes qu'on rencontre si des modifications aussi importantes doivent se faire.
- Les balises absentes produisent en principe un résultat vide qui est ignoré
- les boucles peuvent etre suivie d'un ? pour que le compilateur ne rale pas si la boucle n'est pas definie (cf le core sans le plugin forum).La modif que tu as introduite va donc à l'envers de ces deux points,
...
Avant cette modif, le cas qui posait encore problème etait effectivement les critères.
C'est quelque peu biaisé de donner une conclusion sur la base de prémices incomplets, qu'on complète seulement après le verdict. Le "?" après les boucles est exactement le pendant du "chercher_filtre" que je signalais, les deux sémantiques ont donc le même nombre de contraintes dans le cas du plugin inactif. Dans le cas actif, la nouvelle est plus perfomante, que demande le peuple ?
Du point de vue du compilateur, certes.
Du point de vue des utilisateurs c'est moins évident. Il ne faut pas les oublier.C'est absurde d'opposer le compilateur et les utilisateurs, alors que celui-ci a fait l'objet d'un travail d'amélioration dirigé vers eux. Avec la sémantique précédente, on pouvait avoir le scénario suivant:
1. un utilisateur compile un squelette comportant l'exemple de Mathieu reférensçant le filtre F du plugin P alors inactif.
2. il active le plugin P.
3. il demande une page utilisant le squelette en question: paf, erreur filtre F indéfini.
Si le plugin est actif, le filtre est bien là, justement, et il n'y a pas de problème.
Par ailleurs ton évolution est plutôt bloquante dans le scénario contraire :
- l'admin compile le squelette utilisant le filtre F avec le plugin actif, tout va bien
- il désactive le plugin
- il demande la page utilisant le squelette en question qui est simplement calculée : paf, plantage brutal sans aucun avertissement et page blanche sans aucune explication.
Si on se contente de vérifier la présence des filtres à la compilation, on suppose que son existense n'est pas susceptible de changer ensuite, ce qui dans le cas des plugins n'est pas le cas.
Il est donc bien nécessaire de vérifier l'existence des filtres au calcul, si besoin, pas à la compilation.
pour ma part, c'est ça que j'appelle "oublier les utilisateurs" car c'est incompréhensible.
Ce qu'on peut faire en revanche pour aider à l'abandon de cette sémantique incohérente, c'est que la balise #PLUGIN émette un avertissement si le plugin est inactif pendant la compilation.
Ben non, on ne veut pas d'un avertissement puisque c'est explicitement fait pour fonctionner avec et sans le plugin. Un avertissement systématique ne ferait qu'effrayer les admins qui n'y comprendrait rien.
Cédric
Le 7 septembre 2009 22:27, cedric.morin@yterium.com
Ce qu’on peut faire en revanche pour aider à l’abandon de cette sémantique incohérente, c’est que la balise #PLUGIN émette un avertissement si le plugin est inactif pendant la compilation.
Ben non, on ne veut pas d’un avertissement puisque c’est explicitement fait pour fonctionner avec et sans le plugin. Un avertissement systématique ne ferait qu’effrayer les admins qui n’y comprendrait rien.
Oui, j’allais le dire il faut surtout pas générer un avertissement c’est le principe même de la balise.
Eric
les utilisateurs comprennent très bien qu'activer ou désactiver un plugin nécessite très souvent de vider les caches
S'ils le comprennent, s'ils comprennent aussi qu'il faut mettre un "?" après une table dépendant de la présence d'un plugin, je pense qu'ils peuvent comprendre qu'il faut activer le plugin avant de compiler, ou écrire "chercher_filtre" pour un filtre qui dépend de la présence d'un plugin, surtout si on leur dit qu'il y a un gain de performance et d'aide à la mise au point derrière.
De la même manière qu'un filtre, une balise absente ou une inclusion peut être non trouvée. Le compilateur doit il alors aussi renvoyer des erreurs ? C'est pareil pour les critères (et là, comme eux ne sont pas débrayables, ça me pose effectivement, comme à Cédric ou Sarka des problèmes)
Je suis plutôt content que ma modif ait mis sur le tapis le pb de ces critères qui aurait dû remonter depuis beaucoup plus longtemps sur spip-dev. Je répète que pour les filtres, la solution c'est chercher_filtre qui existe depuis longtemps, et donc que le pb qui reste n'est pas dans cette modif mais dans l'absence d'un "chercher_critere".
Actuellement SPIP ne produit aucun message d'avertissement, seulement des messages d'erreur, ce qui est plutôt le signe d'un manque. On pourrait concevoir qu'un critère indéfini produit un tel message, visible seulement des admin, pas des visiteurs, mais n'empêche pas la compilation de se poursuivre en l'ignorant complètement.
Committo,Ergo:Sum
Avec la sémantique précédente, on pouvait avoir le scénario suivant:
1. un utilisateur compile un squelette comportant l'exemple de Mathieu reférensçant le filtre F du plugin P alors inactif.
2. il active le plugin P.
3. il demande une page utilisant le squelette en question: paf, erreur filtre F indéfini.
Si le plugin est actif, le filtre est bien là, justement, et il n'y a pas de problème.
Je pensais que tu connaissais le compilateur mieux que ça. En cas de filtre indéfini, le compilateur précédent ne provoquait pas d'erreur, mais produisait du code qui, à l'exécution, provoque une erreur. Le scénario que je donne comporte donc un pb, parce que le code produit date d'avant l'activation du plugin.
Par ailleurs ton évolution est plutôt bloquante dans le scénario contraire :
- l'admin compile le squelette utilisant le filtre F avec le plugin actif, tout va bien
- il désactive le plugin
- il demande la page utilisant le squelette en question qui est simplement calculée : paf, plantage brutal sans aucun avertissement et page blanche sans aucune explication.
En effet, mais c'est un scénario moins absurde: il désactive donc ça se passe mal, c'est assez logique. Dans l'autre, il a activé et ça se passe mal quand même, parce qu'il n'a pas activé au bon moment, c'est beaucoup plus tordu.
Si on se contente de vérifier la présence des filtres à la compilation, on suppose que son existense n'est pas susceptible de changer ensuite, ce qui dans le cas des plugins n'est pas le cas.
Il est donc bien nécessaire de vérifier l'existence des filtres au calcul, si besoin, pas à la compilation.
Ce n'est pas faux, mais alors à ce moment là il faut le faire pour tous: entites_html, textebrut etc etc car qui nous dit qu'une surcharge de fitlres.php, texte.php etc n'ont pas rendu ces fonctions indisponibles ? Ce serait plus sûr, mais bonjour les perfs. Je trouve beaucoup plus simple de dire:
1. pour utiliser critères, filtres et balises d'un plugin, il doit être actif à la compilation
2. si vraiment vous voulez rendre un plugin actif par intermitence, utiliser chercher_filtre.
Committo,Ergo:Sum
Je répète que la sémantique précédente remplaçait l'actuelle erreur à la compil par une erreur à l'exécution même après activation du plugin. Qu'est-ce quei est le plus effrayant, cette sémantique absurde ou un message d'avertissement disant que la balise PLUGIN référence un objet inconnu ? Et pourquoi parler de systématisme, puisqu'il ne s'agit que de la compilation lancée par un admin ?
Committo,Ergo:Sum
Tu n'as pas montré comment utiliser chercher_filtre dans un squelette. Je voudrais bien un exemple si c'est possible. Merci.
* Committo,Ergo:sum tapuscrivait, le 07/09/2009 22:48:
Avec la sémantique précédente, on pouvait avoir le scénario suivant:
1. un utilisateur compile un squelette comportant l'exemple de Mathieu reférensçant le filtre F du plugin P alors inactif.
2. il active le plugin P.
3. il demande une page utilisant le squelette en question: paf, erreur filtre F indéfini.Si le plugin est actif, le filtre est bien là, justement, et il n'y a pas de problème.
Je pensais que tu connaissais le compilateur mieux que ça. En cas de filtre indéfini, le compilateur précédent ne provoquait pas d'erreur, mais produisait du code qui, à l'exécution, provoque une erreur. Le scénario que je donne comporte donc un pb, parce que le code produit date d'avant l'activation du plugin.
Il me semble que cet exemple est bien théorique (et esthétique aussi d'ailleurs).
En pratique, quand j'active un plugin (ou le désactive), je vide le cache de SPIP (et parfois, du navigateur aussi).
Et Cédric n'a pas forcé ce vidage à la désactivation des plugins pour que la désactivation accidentelle du plugin Accès Restreint ne rende pas accessible un contenu qui ne devrait pas l'être.
Yo,
On l'appelle via appliquer_filtre. Il y a des exemples dans les modèles std:
[(#ID_DOCUMENT|appliquer_filtre{#MIME_TYPE})]
[(#FICHIER|contenu_document{#ENV{charset,auto}}|appliquer_filtre{#MIME_TYPE,filtre_text_txt_dist})]
etc.
Committo,Ergo:Sum
Mais ça se perd en conjectures là !
On parle de cas où on ne veut PAS gérer l'indisponibilité d'une fonction. Il ne DOIT PAS y avoir d'erreur car ce n'est pas un squelette à MODIFIER mais bien un squelette GENERIQUE qui génère telle ou telle fonctionnalité EN PLUS si tel ou tel plugin est activé.
C'est quand même simple à comprendre non ? Surtout qu'il suffit de lire la zone pour voir que c'est une chose extrêmement courante.
Il existe maintenant des dizaines d'exemples de squelettes qui <utilise> des plugins et qui veulent ajouter des fonctionnalités uniquement lorsque tel ou tel plugin est actif.
À aucun moment ce genre de cas ne doit aboutir à une erreur, puisque les admins ne vont absolument pas modifier ensuite le squelette à chaque activation/désactivation. Le but étant justement de vouloir marcher dans les DEUX cas !
Que la syntaxe change, soit. Mais à ce moment là, il faut dire clairement comment on doit désormais gérer ce cas.
Le pb est dans le contenu de ce bloc: s'il utilise des filtres du plugin, il faut absolument avertir, s'il n'en utilise pas, effectivement le message est inutilement alarmant. C'est juste une idée que j'ai eue face à une situation qui est est insatisfaisante dans l'ancienne version comme dans la nouvelle.
Committo,Ergo:Sum
* Committo,Ergo:sum tapuscrivait, le 07/09/2009 22:48:
Avec la sémantique précédente, on pouvait avoir le scénario suivant:
1. un utilisateur compile un squelette comportant l'exemple de Mathieu reférensçant le filtre F du plugin P alors inactif.
2. il active le plugin P.
3. il demande une page utilisant le squelette en question: paf, erreur filtre F indéfini.Si le plugin est actif, le filtre est bien là, justement, et il n'y a pas de problème.
Je pensais que tu connaissais le compilateur mieux que ça. En cas de filtre indéfini, le compilateur précédent ne provoquait pas d'erreur, mais produisait du code qui, à l'exécution, provoque une erreur. Le scénario que je donne comporte donc un pb, parce que le code produit date d'avant l'activation du plugin.
Il me semble que cet exemple est bien théorique (et esthétique aussi d'ailleurs).
En pratique, quand j'active un plugin (ou le désactive), je vide le cache de SPIP (et parfois, du navigateur aussi).
Pareil.
Et Cédric n'a pas forcé ce vidage à la désactivation des plugins pour que la désactivation accidentelle du plugin Accès Restreint ne rende pas accessible un contenu qui ne devrait pas l'être.
Pour éviter cela, et permettre le vidage automatique du cache, serait-il envisageable que le plugin Accès Restreint utilise plutôt un statut "restreint" en remplacement de "publié" sur les rubriques, comme ça si le plugin est désactivé, les contenus sont tout de même protégés ?
-Nicolas