Re: Critères optionnel avec opérateur : doc imprécise ou bug?
Cerdic <[email protected]>
| Newsgroups | gmane.comp.web.spip.devel |
|---|---|
| Message-ID | <4421c641-c46e-4180-b46a-80732e7c2089@Spark> |
oui mais non.
En fait je pense que cette extension du {id_article?} initial était une fausse bonne idée.
Le fonctionnement actuel est lié à plusieurs raisons qui ne sont certes pas de bonnes raisons, mais les justifications techniques :
• au départ existait uniquement {id_article?} donc qui testait implicitement l’existence d’un #ENV{id_article} et le cas échéant le prenait en compte et sinon ignorait le critère
• l’extension sous la forme {id_article?=#ENV{truc}} est donc une extension de ça et continue à tester uniquement la présence de #ENV{id_article}
• id_article est forcément statique, et on sait quoi vérifier, c’est énonçable lors de la compilation
• #ENV{truc} est totalement dynamique et peut aussi bien être #ENV{#GET{toto}} ou #GET{truc} quoi que ce soit d’autre, autant dire que "vérifier que dans le #ENV on a cette variable » n’a plus de sens
• a la limite il faudrait étendre avec quelque chose du genre « si le membre utilisé pour la comparaison est null, on ignore la condition, sinon on l’applique » car c’est ce qui s’approche le plus de « il y a une variable id_article dans le env}
• mais voila, le compilateur est ainsi fait que l’on caste a tous les etages, et je ne pense pas qu’on soit en mesure de distinguer véritablement la valeur null (=pas de valeur) d’une liste vide par exemple (qui doit donc retourner une selection vide) ou d’une valeur zéro
Bref, il y a bug quelque part, mais peut-être à l’introduction même de cette feature que je prends soin de ne jamais utiliser car trop ambigu et incertaine à mon avis (sans compter que si un jour on est capable de lui donner le sens attendu, ça cassera tous les usages...)
--
Cédric
Le 16 déc. 2020 à 13:47 +0100, RastaPopoulos <[email protected]>, a écrit :
> Le 16/12/2020 à 13:32, Maïeul Rouquette a écrit :
> > Donc : incompréhension de la doc, ou bug ?
>
> Les deux :p
>
> 1) La doc c'est pas assez clair et oui il faudrait être encore plus explicite que ça.
>
> 2) Moi je considère que c'est au moins un demi-bug, un gros gros manque, car à partir du moment où un critère permet de préciser *ce qu'on veut* comme comparaison à droite : un #ENV ou un #GET ou un #ARRAY etc, alors c'est ÇA qui devrait être testé si vide ou pas. En effet, ce n'est pas parce qu'il existe le critère {truc} qu'on va vouloir l'utiliser QU'UNE unique fois dans la boucle, et que donc c'est forcément #ENV{truc} qu'il faut tester. Si par exemple on a plusieurs filtres sur le même critère : {truc #ENV{filtre1}} {truc #ENV{filtre2}} : c'est bien ces deux valeurs là qu'on veut tester. Et à peu près tout critère peut être utilisé autant de fois qu'on veut !
>
> --
> RastaPopoulos
>
> _______________________________________________
> liste: https://listes.rezo.net/mailman/listinfo/spip-dev
> doc: https://www.spip.net/
> dev: https://core.spip.net/
> irc://irc.freenode.net/spip