Je ne sais pas si cela est un bug ou pas mais j’ai remarqué un comportement bizarre sur les itérateurs en spip 3.3 (j’ai pas testé pour les versions précédentes) concernant le critère {a, b}.
Je voulais avoir la liste des 30 premiers éléments contenus dans un fichier JSON.
Donc j’ai fait une boucle DATA avec la source json et le critère {0, 30}.
Rien à faire j’obtiens les 500 éléments du JSON.
J’ai regardé sur une autre boucle DATA de type source tableau et là ça fonctionne.
Je ne vois pas le rapport d’ailleurs car JSON ou pas on revient toujours à un tableau.
Autre chose, la balise #GRAND_TOTAL combinée au critère {a, b} renvoie le nombre total d’élément du tableau et pas le “b”. Est-ce normal ?
t’aurais pas un JSON avec un tableau d’une entrée qui elle contient ensuite 500 éléments ?
Auquel cas un datapath pour extraire directement le 2nd niveau devrait faire l’affaire car ensuite le critère s’appliquera bien sur ta liste de 500 éléments
Je viens de m’apercevoir d’un autre truc c’est que je mets une pagination de 10 e n10.
Dès que je dépasse les 30 il n’affiche plus rien comme si là il prenait en compte mon critère {a, b}
Autre chose, la balise #GRAND_TOTAL combinée au critère {a, b} renvoie le nombre total d'élément du tableau et pas
le "b". Est-ce normal ?
Je viens de m'apercevoir d'un autre truc c'est que je mets une pagination de 10 e n10.
Dès que je dépasse les 30 il n'affiche plus rien comme si là il prenait en compte mon critère {a, b}
J'avais aussi constaté ça et exploré le code pour comprendre.
De mémoire et donc je n'exclue pas des approximations, voici ce dont je me souviens :
Cette singularité se produit parce que les boucles DATA fonctionnent en plusieurs étages :
- Le premier étage ne prend en compte qu'une partie des critères, mais pas tous.
Notamment ça ne prend pas en compte les {a,b}
C'est le résultat de ce premier filtrage partiel qui est mis dans le cache spécifique aux DATAs.
- Le 2eme étage récupère ce cache et applique dessus les critères qui n'ont pas encore été appliqués.
C'est pertinent lorsque la boucle porte sur un grrrrooos fichier distant,
puisque ça permet d'interroger internet qu'une seule fois pour le récupérer,
et de recadrer les usages ultérieurs à partir de la version locale seulement.
Et je me suis dit que c'est ce cas d'utilisation qui historiquement a motivé ce fonctionnement.
Les phénomènes dérogatoires que tu constates en sont la conséquence.
À l'époque je voulais créer une boucle DATA pour itérer sur les caches de mémoization,
et j'avais envisagé coder un fonctionnement alternatif
car le fonctionnement en 2 étages n'apporte rien quand la ressource est locale et immédiatement disponible.
>> Autre chose, la balise #GRAND_TOTAL combinée au critère {a, b} renvoie le nombre total d'élément du tableau et pas le "b". Est-ce normal ?
Je viens de m'apercevoir d'un autre truc c'est que je mets une pagination de 10 e n10.
Dès que je dépasse les 30 il n'affiche plus rien comme si là il prenait en compte mon critère {a, b}
J'avais aussi constaté ça et exploré le code pour comprendre
et produit une alternative : la boucle SMARTDATA
Il y a un repo pour ces travaux : jluc / smartdata · GitLab
Il y a une documentation et une analyse de cette alternative dans le readme.
Ça dit que ça marchait bien.
En l'état c'est une nouvelle boucle (SMARTDATA)
mais j'envisageais que ce fonctionnement puisse enrichir le fonctionnement
des boucles DATA au moyen d'un nouveau critère {smart} ...
Accessoirement il y a un autre plugin pour boucler en SPIP, avec DATA ou SMARTDATA,
sur les caches de memoization : jluc / memoization.dev · GitLab
Si on doit sortir une 3.3 ça vaudrait pas le coup quand même de jeter un oeil sur ce sujet qui a bien l’air d’être un bug.
Autre alternative, on change la doc mais ça fait un peu naze.