comment ça marche : le cache de pages
Dans inc-public
, l’appel à calcule_header_et_page
s’occupe de ce point. Cette fonction est dans
inc-public-global
.
Là :
- on récupère les infos de sessions et la langue à utiliser.
- en passant, on traite le cas d’un envoi de formulaire (forum ou pétition), et on regarde si on est en debug ou s’il faut afficher le
formulaire d’admin. - on appelle
afficher_page_globale
- tripatouillages pour savoir si on est en preview, en recalcul ...
- appel à
generer_nom_fichier_cache
(dans inc-cache
), c’est là que ça se passe : on lui passe un fond
et un contexte et ça retourne un nom de fichier.
Là, le contexte est vide, on prend donc l’uri, nettoyée de certains paramètres (nettoyer_uri
). Dans le cas d’un tag
<inclure>
je suppose que ce sont les paramètres de l’inclure.
on mouline alors tout ça à coup de hash pour en faire un nom de fichier qui à toutes les chances d’être unique. - appel à
determiner_cache
(dans inc-cache
) : pour savoir si on a ce qu’il faut en cache
-
utiliser_cache
(dans inc-cache
) : si le fichier n’existe pas, qu’il est trop vieux ou que var_mode ( ??),
il n’est pas utlisable. - si on ne doit pas, mais que la base est hs, on le prend quand même
- si c’est un post, on prend pas ( ?)
- à la fin de ces bricoles, on a une variable
use_cache
qui contient ce que son nom indique - appel à
obtenir_page
(dans inc-public-global
) :
- si on ne peut pas utiliser le cache, inclusion de
inc-calcul
, appel de calculer_contexte
(qui stocke les
arguments de l’url et la date dans un tableau) puis de calculer_page
. Là, on passe la main à
l’évaluateur de squelettes. - sinon (cache ok), appel à
lire_fichier
, puis tambouille tordue (là, je décroche complètement ...)
- dans les 2 cas, on récupère et retourne une variable tableau dont l’entrée ’texte’ contient le code de la page, ouf.
- on prépare l’entête de retour (status si erreur, no cache s’il y a des données volatile dans la page ...)
- on balance le tout en retour
[Erreur...5]