Voici la proposition pour ajouter un pipeline juste avant le calcul du
PHP en HTML qui permet d'avoir accès au tableau de contexte pour faire
ces calculs.
Cela permet de faire des ajouts ou modifs avant le cache, comme changer
un tri par défaut, ajouter un drapeau qui sera récupérer plus tard, etc.
Cela ne change strictement rien, c'est juste une porte en plus, mais
permet des choses pour celleux qui en auraient besoin. Donc je montre le
patch là, et je propose de l'ajouter en trunk et backporter en 3.2
puisque ça ne change rien.
Pour le nom j'ai mis "contexte_pre_calcul", peut-être qu'il y a mieux.
pipeline_pre_calcul.patch (881 Bytes)
Après discussion sur IRC, en fait le nom du fichier de cache est défini
bien avant. Donc si on change l'ENV, il ne faut pas le même cache.
Le pipeline devrait donc se trouver avant le calcul du nom du cache.
On aurait plus forcément la date, car elle est ajoutée là où j'avais mis
le pipeline au départ, mais c'est pas très grave.
Il y a deux cas :
- pour la page racine dans assembler()
- pour les inclusions dans inclure_page()
Pour le deuxième cas, c'est facile, et le cache dépend du contexte. Si
on modifie le contexte avant, ça va modifier le nom du cache.
Pour la page complète par contre, Cédric rappelle que le cache n'est pas
dépendant du contexte, mais uniquement de l'URL demandée. Donc là il
faut trouver un moyen de ne pas dépendre du même cache si jamais on a
modifié le contexte. Encore un truc à résoudre donc pour ce pipeline.
Voici la proposition pour ajouter un pipeline juste avant le calcul du
PHP en HTML qui permet d'avoir accès au tableau de contexte pour faire
ces calculs.
Ok. 
Cela permet de faire des ajouts ou modifs avant le cache, comme changer
un tri par défaut, ajouter un drapeau qui sera récupérer plus tard, etc.
Cela ne change strictement rien, c'est juste une porte en plus,
Donc, ça ajoute une porte, c'est pas rien 
mais
permet des choses pour celleux qui en auraient besoin. Donc je montre le
patch là, et je propose de l'ajouter en trunk et backporter en 3.2
puisque ça ne change rien.
Dans l'absolu, tu enrichis en ajoutant une nouvelle fonctionnalité sans
introduire de BC Break : ça change une API.
Un changement rétrocompatible d'API nécessite d'incrémenter la version
mineure du logiciel...
Comme la version de SPIP ne reflète pas vraiment son API...
Donc pas d'objection, juste ce petit pinaillage pour rappeler la théorie ^^
et que dans la pratique l'API de SPIP mériterait qu'on y réfléchisse. 
Pour le nom j'ai mis "contexte_pre_calcul", peut-être qu'il y a mieux.
C'est avant l'appel à public/composer (oh, on en avait déjà un, dis-donc
:D) On pourrait sans doute trouver moins vague que "calcul" :
contexte_pre_composition ?
Il faudra documenter que les fonctions qui seront codées pour s'enregistrer
dans ce pipeline devront retourner uniquement la partie 'data' du tableau
passé en paramètre.
/**
* Les modifs de contexte de mon plugin "prefix".
C'est avant l'appel à public/composer (oh, on en avait déjà un, dis-donc
:D) On pourrait sans doute trouver moins vague que "calcul" :
contexte_pre_composition ?
Ce n'est pas ce que j'avais compris, mais j'ai peut-être encore compris
de travers. 
Dans ma mémoire, "composer" c'est la compilation du squelette (template)
en PHP. Le contexte n'entre pas en ligne de compte pour transformer en
squelette en PHP, il est utilisé uniquement pour le calcul final :
transformer le PHP en HTML, suivant possiblement la base de données etc.
Donc le contexte est plutôt lié au "calcul" qu'à la "composition", par
rapport à ce que j'avais compris.
Il faudra documenter que les fonctions qui seront codées pour
s'enregistrer dans ce pipeline devront retourner uniquement la partie
'data' du tableau passé en paramètre.
Papyyyyyy relis la doc des pipelines.
Depuis le début que les pipelines existent, il y a deux sortent de
pipelines : ceux dont le flux correspond directement au contenu
modifiable, et ceux dont le flux est un tableau normé avec uniquement
deux clés "args" (le contexte d'où on est) et "data" le contenu modifiable.
Dans tous les cas les utilisateurices doivent retourner le flux complet
de départ. C'est la fonction pipeline() qui ensuite ne revoit que "data"
tout à la fin, c'est prévu.
Est-ce qu'il ne faudrait pas aussi ajouter ce pipeline dans
ecrire/paquet.xml ?
Si si bien sûr, là je n'ai montré que ce que je voulais modifier dans le
code (mais comme le dit mon autre email, en fait ce n'est pas au bon
endroit et faut encore réfléchir pour le squelette racine).
Quand on touche au cache prudence est mère de sûreté et je suis d’avis de prendre le temps de tester/debug un peu sérieusement sur la version de développement avant d’envisager un backport en 3.2…
Oui c'est vrai, je n'avais pas trop pensé à cette histoire de tester si
on cherchait le bon cache.
OK 
Je suis clairement à la ramasse. 
Je ne vais pas remettre en cause ce fonctionnement, mais je le trouve
contre-intuitif. Un pipeline, ou un middleware, devrait renvoyer un
"objet", ou disons plutôt structure pour l'instant, de même type que celui
qu'il reçoit. C'est ce que font les fonctions exécutées, mais aussi ce que
devrait faire la fonction pipeline() elle-même.
ça ne change rien au fait que c'est une bonne idée d'introduire ce nouveau
point d'entrée, reste à trouver sa place
Calomnie. 
En fait ce n'est pas du tout ce que je vois dans le code pour l'instant,
mais peut-être je comprends mal.
J'ai donc fouillé pour assembler() qui s'occupe des squelettes racines,
et ça marche… exactement pareil que pour inclure_page() !
Sauf que là le contexte n'est pas fourni manuellement dans un tableau,
mais est généré automatiquement en aspirant GET et POST mélangé. Mais
ensuite ça fait exactement la même chose et ça envoie tout ça à la
fonction public_cacher() qui génère un nom de cache *en fonction du MD5
du contexte*. Tout comme pour les inclusions.
Donc en fait il n'y a aucun différence, à part que c'est en deux
endroits (bof, yorait sûrement des choses à mutualiser).
Et donc on peut bien mettre à ces deux endroits le même pipeline *avant*
la fonction de cache, afin de pouvoir modifier le contexte, et ça va
bien être pris en compte pour le cache.
Me semble pas, car la suite du code ne travaille pas sur le contexte, le
contexte est utilisé pour calculer/produire la page (et le nom du cache).
pre et post boucle c'est parce que c'est avant et après la fonction qui
définie la boucle et qui travaille dessus.
Là d'une part c'est pas avant le contexte mais bien après qu'il ait été
défini (donc pre_contexte ça va pas), et deuxièmement c'est pas avant
une fonction qui travaille le contexte, c'est avant le cache et avant
produire_page.
Mais ça ne peut pas être "pre_cache" ou "pre_produire_page", puisque le
contenu du pipeline n'est pas de modifier le cache ni la page, mais bien
le contexte.
D'où : contexte_pre_calcul, ou contexte_pre_produire_page… = sur quoi ça
travaille (le contexte) et quand (avant le cache ou avant produire_page.
Mais produire_page c'est le point d'entrée de l'ensemble (y compris le
"recalcul" càd la vraie compilation template=>PHP.
Un truc bizarre c'est que "calcul" est un terme qui n'apparait pas en
fait dans tous les processus. Alors que c'est bien ce terme qui désigne
l'opération PHP => HTML, avec var_mode=calcul.
M'est-avis que c'est le nom le plus connu et qui regroupe toute
l'opération et c'est bien ce qu'on veut faire : permettre de modifier le
contexte avant le calcul de PHP en HTML.
Donc contexte_pre_calcul
Et donc voilà cette fois le patch complet avec le XML et les deux
appels, une pour les squelettes racines et une pour les inclusions.
J'ai mis "contexte_pre_calcul"
(ça pourrait être "pre_calcul_contexte" aussi, mais plus confus car ça
peut se comprendre en "avant le calcul du contexte" ce qui est faux)
contexte_pre_calcul.patch (2.16 KB)
Encore des précisions et questionnement.
Pour les squelettes racines, à ce niveau là où pour l'instant est le
pipeline, on n'a aucune info de quel fond est demandé et l'identifiant
de l'objet s'il y en a un etc, car ça c'est cherché plus loin. On a
effectivement (un peu comme le disait Cédric) que l'info de "quel URL
est demandé".
MAIS il n'empêche que si on ajoute des infos de contexte à ce moment là,
elles sont bien prises en compte pour la génération du nom du cache.
Mais le but c'est que ce pipeline soit bien *avant* le cache, donc c'est
comme "affichage_final" : c'est à utiliser en faisant attention à son
code, en ne faisant pas des opérations lourdes, et surtout normalement
en n'essayant de ne *pas faire de requête SQL*, puisque sinon le cache
ne sert à rien (vu qu'il permet en théorie d'avoir des pages mêmes quand
le SQL est coupé).
Bref par cohérence, pour les racines dans assembler() ça devrait bien
être là mais on a alors ni "fond" ni "contexte" rempli (array vide)
Y a-t-il un intérêt ? Pour que ce soit pareil partout je dirais oui, il
peut toujours y avoir quelque intérêt même sans connaitre le fond.
Sinon l'autre alternative ce serait de dire que ce n'est que pour les
inclusions, et on renomme alors le pipeline : pre_contexte_inclusion
Moi dans mes quelques idées d'utilisations, à chaque fois c'est pour des
inclusions, mais sait-on jamais…
Et surtout j'ai du mal avec l'idée que ça ne marche pas pareil entre
squelettes racines et inclus, pour moi dans les deux cas ce sont des
squelettes à compiler et à calculer. Je trouve cela dérangeant que ça ne
fonctionne pas pareil.