Re: Itérateurs et critère {a, b}
JLuc <[email protected]>
| Newsgroups | gmane.comp.web.spip.devel |
|---|---|
| Message-ID | <[email protected]> |
Le 10/02/2020 à 09:35, Eric Lupinacci a écrit :
>> 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.
JLuc