je lis
"Le test est ainsi effectué uniquement si la valeur désignée est présente dans l’environnement, sinon le critère est ignoré."
spontanément je comprend "la valeur désignée" comme la valeur à droite de l'opérande, mais en réalité c'est la valeur d'environnement homonyme à ce qui est à gauche de l'opérande.
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 !
Oui c’est plus clair.
Néanmoins, les exemples de l’article montrent que le cas de Maieul n’est pas bon avec le #ENV{toto}.
En fait, je ne sais pas si je dis une connerie (c’est possible hein) mais le #ENV{variable} est presque inutile puisqu’on va chercher une variable de même nom que le critère lui-même ?
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...)
J'aurais tendance à penser que sous réserve des problèmes techniques, ton point « si le membre utilisé pour la comparaison est null, on ignore la condition, sinon on l’applique » serait idéal. Par contre oui le problème de la conversion de type risque certainement de nous bloquer. Peut être ouvrir un ticket et si un jour on trouve une solution miracle on résoudra?
Et pour éviter de casser les usages, on pourrait imaginer un forme
{id_truc IN ?#GET{machin}}
après pour l'heure on peut se débrouiller avec le fonctionnement actuel, suffit de multiplier les inclusions en amont (encore que {date <? #ENV{borne1}} {date ?>{#ENV{borne2}}, je sais pas comment on fait)
Et pour éviter de casser les usages, on pourrait imaginer un forme
{id_truc IN ?#GET{machin}}
Pour introduire encore un peu plus de complexité avec ce point d'interrogation ?
Je ne sais pas si c'est une bonne idée.
après pour l'heure on peut se débrouiller avec le fonctionnement actuel, suffit de multiplier les inclusions en amont (encore que {date <? #ENV{borne1}} {date ?>{#ENV{borne2}}, je sais pas comment on fait)
franchement, non, on va pas compliquer ce critère déjà incompréhensible.
Limite toi à {id_bidule?} et pour le reste du fait un critère personalisé si besoin.
Le jour où on saura faire un critère conditionnel compréhensible et utilisable avec un opérateur, on aura pas de remords à casser la compat vu comment l’existant ne fonctionne pas vraiment
comme dit en privé (erreur de ma part) je n'ai jamais suggéré de créer ce critère, puisue je disais précisement que cela ferait une syntaxe absconne...
franchement, non, on va pas compliquer ce critère déjà incompréhensible.
Limite toi à {id_bidule?} et pour le reste du fait un critère personalisé si besoin.
Le jour où on saura faire un critère conditionnel compréhensible et utilisable avec un opérateur, on aura pas de remords à casser la compat vu comment l’existant ne fonctionne pas vraiment
Par contre (il me semble qu')une nouvelle syntaxe serait assez spontanée à adopter :
les arguments optionnels d'inclusion,
passés à l'inclusion seulement s'ils sont définis dans l'environnement
(en l'absence de l'argument 'env').
J'ai eu la curiosité de chercher la zone,
et j'ai constaté que 3 ou 4 squelettes utilisaient déjà cette possibilité.
C'est assez spontané de faire ça
et ça semble utile pour cibler les variables d'{env} qu'on passe à la noisette.
Dans certains cas, ça peut éviter de multiplier les caches avec {env}
(et de diviser d'autant leur efficacité).
Malheureusement cette syntaxe et la fonctionnalité associée n'existent pas encore !
On a que le choix de passer {id_rubrique} ou {env}.
Il y aurait donc un intérêt à Ouvrir cette Syntaxe Potentielle
et réaliser le voeux d'un <INCLURE{fond=inc-rubriques}{id_rubrique ?}>
