Hello,
[…]
Pour cela j’ai utilisé le critère {id_?} et le pipeline
lister_champs_selection_conditionnelle.
Voilà mon feedback et quelques idées d’évolutions à discuter.
Ce que je voulais exprimer en indiquant que ce pipeline n’était peut
être pas une bonne idée, c’est justement un cas comme tu présentes, qui
appelles un autre champ que « id_qqc » (il y a déjà « objet » parfois aussi
de mémoire). C’est pour cela que je pense que {id_?} ou {id_*?} est
correctement nommé, pour l’usage que je lui supposais.
Peut être qu’il faut alors un autre critère, et peut être pas de
pipeline sur le premier d’ailleurs) pour ton/cet autre usage.
Oui c’est possible.
Le critère id_? a du sens quand il permet « automatiquement » de créer des conditions basées sur les id identifiées en fonction de la boucle et des tables liées…
Là où à mon avis ça perd de son sens c’est quand on utilise un pipeline qui permet d’injecter d’autres critère comme le mien est_archive.
Ca devient alors comme tu le dis un tout autre critère.
Ou sinon, comme tu dis, il faut renommer le critère pour quelque chose
de plus général, mais les noms que tu proposes me laissent plutôt
perplexe, notamment car ça n’a rien à voir techniquement avec le critère
{where}.
Là je ne suis pas d’accord.
Si on en fait un critère plus général il y a des similitudes avec le critère {where}.
Le critère {where} attend une condition dans une variable « where » du contexte et la condition doit être totalement compilée.
Le critère {id_?} ou autre nomenclature traduit in fine un where mais qui n’est pas immédiat dans le contexte : il doit être calculé à partir d’éléments du contexte non définis en opérande du critère. Pour moi c’est une sorte de where mais dynamique ce qui justement nécessite de passer par un pipeline pour fournir cet opérande.
Le fonctionnement recherché pour les listes d’objets :
1- si aucun critère d’archivage n’est précisé (explicite ou implicite
via id_?) je n’affiche pas les objets archivés
2- on doit pouvoir afficher que les objets archivés
3- on doit pouvoir afficher tous les objets archivés ou pas
Il y a également un problème d’ordre dans les critères ; pour que {id_?}
et l’appel de ton pipeline puisse détecter que le critère « archive » est
utilisé, cet appel à archive doit arriver avant le critère id. ie.:
{archive=1}{id_?} et pas {id_?}{archive=1} ;
Ce qui est déjà en soit une limitation sur {id_?} .
Je te suis pas trop là mais je crois que mon explication n’était pas claire non plus.
A mon avis c’est un sujet mineur car j’ai réussi à faire fonctionner les trois cas.
[…]
Après, lors de la discussion qui a mené à cette implémentation, il avait
été proposé d’appeler une fonction de calcul du critère si elle existe :
Tu peux rafraichir nos mémoires parce que je ne vois pas à quoi ça
pourrait faire allusion ?
Oui, c’était Cédric qui proposait :
Une solution à laquelle je pense serait de faire un critère spécifique genre {selection_conditionnelle} (nomenklatura si tu as mieux on prend !) qui regarderait les id_xxx connus dans l’environnement et pour chaque chercherait une fonction du type inc_generer_condition_selection_{id_xx}dist qu’on appelerait sur le mode
$generer_condition_selection = charger_fonction(‘generer_condition_selection’.$primary,’inc’);
$boucle->where = $generer_condition_selection($type_boucle,champ_sql($primary));
J’ai d’ailleurs patché le critère id_ pour insérer un tel mécanisme et ça fonctionne très bien.
Ca m’a permis de simplifier mon post_boucle.
ce n’est pas le cas actuellement et ça serait bien de l’introduire car
dans mon cas je suis obligé de capturer a posteriori , via le pipeline
post_boucle, le where calculé par le critère id_ pour le modifier étant
donné qu’il n’introduit pas la valeur par défaut (tout sauf les
archives) si aucune variable « est_archive » n’est définie dans
l’environnement.
C’est bien ce qui me fait dire que ce n’est pas le même besoin, et donc
probablement pas le même critère ou le même mécanisme à utiliser.
[…]
Il faut en discuter donc 
Pour être clair en terme de code.
En utilisant id_ pour mon besoin j’obtiens par défaut le where suivant (le truc important est en bleu) :
**array** *(size=4)*
0 => <small>string</small> ''?'' *(length=3)*
1 => <small>string</small> '!(is_array(@$Pile[0]['est_archive'])?count(@$Pile[0]['est_archive']):strlen(@$Pile[0]['est_archive']))' *(length=102)*
2 => <small>string</small> ''='' *(length=3)*
3 =>
**array** *(size=4)*
0 => <small>string</small> ''?'' *(length=3)*
1 => <small>string</small> '(is_array(@$Pile[0]['est_archive']))' *(length=36)*
2 => <small>string</small> 'sql_in('articles.est_archive',sql_quote($in8))' *(length=46)*
3 =>
**array** *(size=3)*
0 => <small>string</small> ''='' *(length=3)*
1 => <small>string</small> ''articles.est_archive'' *(length=22)*
2 => <small>string</small> 'sql_quote(@$Pile[0]['est_archive'], '','tinyint(1) NOT NULL DEFAULT \'0\'')' *(length=75)*
Alors que moi je voudrais, dans le cas où est_article n’est pas fourni un critère d’exclusion des archives soit :
**array** *(size=4)*
0 => <small>string</small> ''?'' *(length=3)*
1 => <small>string</small> '!(is_array(@$Pile[0]['est_archive'])?count(@$Pile[0]['est_archive']):strlen(@$Pile[0]['est_archive']))' *(length=102)*
2 =>
**array** *(size=3)*
0 => <small>string</small> ''='' *(length=3)*
1 => <small>string</small> ''est_archive'' *(length=13)*
2 => <small>int</small> 0
3 =>
**array** *(size=4)*
0 => <small>string</small> ''?'' *(length=3)*
1 => <small>string</small> '(is_array(@$Pile[0]['est_archive']))' *(length=36)*
2 => <small>string</small> 'sql_in('articles.est_archive',sql_quote($in8))' *(length=46)*
3 =>
**array** *(size=3)*
0 => <small>string</small> ''='' *(length=3)*
1 => <small>string</small> ''articles.est_archive'' *(length=22)*
2 => <small>string</small> 'sql_quote(@$Pile[0]['est_archive'], '','tinyint(1) NOT NULL DEFAULT \'0\'')' *(length=75)*
C’est ce que je fais dans le post_boucle quand il n’y a aucun critère archive précisé.
Et c’est vrai qu’en y réfléchissant, ce n’est peut être pas la bonne méthode d’utiliser id_ sauf que pour l’instant je ne vois pas d’autre méthode.
Et toi?
!