Carnet Wiki

Version 2 — November 2018 JLuc

Balise #CACHE étendue

Cache de durée dynamique et contextuelle

Dans le core, la durée de cache spécifiée par #CACHE ne sert presque jamais (sauf quand c’est 0 ou quand le site est en lecture seule) puisque tout est invalidé à chaque création ou modification de contenu par un internaute, avant donc l’expiration du cache.

Lorsque Cachelab a permis de supprimer toutes les invalidations globales du site et qu’il ne reste que des invalidations ciblées, alors la durée indiquée pour le cache est réellement utilisée puisqu’il n’y a pas d’invalidations prématurées. La balise #CACHE se révèle alors parfois insuffisante pour coller aux besoins de certaines noisettes lorsque la durée du cache doit varier selon les moments et le contexte.

Cela se présente par exemple lorsqu’on veut indiquer l’âge d’un article, depuis “déposé à l’instant” jusqu’à “il y a 2 ans” en passant par “Il y a 15 secondes”, “il y a 2h”, “hier”, “la semaine dernière” ou “il y a 6 mois” etc. Lorsque l’article est tout frais, la noisette doit être très souvent mise à jour (toutes les minutes au début !), alors qu’après 3 mois, on peut se satisfaire d’une indication plus approximative : “il y a 5 mois” (la progression de la durée est visible dans le source. Bref, la durée du cache doit dépendre de l’âge et de la précision voulue. Or la balise #CACHE n’accepte que des valeurs numériques et ne permet pas de faire des calculs pour établir la durée du cache.

Pour permettre cela CacheLab surcharge la balise #CACHE. Lorsqu’on veut spécifier une fonction de calcul de durée dynamique d’un cache pour un squelette :
-  Le 1er argument est toujours indiqué pour assurer un fonctionnement correct du site en cas de désactivation du plugin cachelab.
-  le 2eme argument ’duree-methode’ commence toujours par le préfixe ’duree-’ et la suite indique la méthode. La fonction cachelab_duree_methode doit être définie. C’est elle qui est appelée pour calculer dynamiquement la durée.
Exemple : #CACHE{1200,duree-progapprox} : le cache aura une durée progressive approximative calculée par la fonction cachelab_duree_progapprox.

Si elle est définie par l’utilisateur, cette fonction recevra la valeur de date_creation issu de l’environnement de chaque cache. Souvent, c’est un champ de l’objet principal affiché par le squelette. Si nécessaire, on peut préciser un autre élément du contexte immédiatement aprés le nom de la méthode.
Exemple : #CACHE{1200,duree-progapprox date_naissance}

Une seule méthode est livrée avec le plugin : progapprox. Elle renvoie une durée de cache de 10 secondes lorsque la date_creation date de moins d’une minute, qui augmente progressivement avec l’âce du cache, jusqu’à valoir 6 mois pour les objets de plus de 2 ans.
Il appartient au webmestre de coder la fonction qui implémente la méthode de ses besoins, ainsi que le filtre d’affichage de la date apparié.

Filtrage post-calcul d’un cache

Un autre 2eme argument est possible : filtre-unefonction. La fonction cachelab_filtre_unefonction qui est appelée après le calcul du cache reçoit le cache entier (sa durée, le contexte et ses autres métadonnées ainsi que le code compilé) et peut le modifier puis éventuellement mettre à jour la version mémoizée. On peut également passer un paramètre constant. C’est un post-processing dont les possibilités sont encore inexplorées.

Exemple : #CACHE{1200,filtre-bidouille grave} appelle, aprés chaque calcul et enregistrement d’un cache, la fonction cachelab_filtre-bidouille avec le cache et l’argument ’grave’.

Stratégie de mise en oeuvre sur votre site

Cette partie porte uniquement sur l’usage de l’API cachelab_filtre . D’autres outils ont été développés depuis

L’usage dépend de chaque site.

Voici 2 marches à suivre pour concevoir comment utiliser CacheLab sur un site existant. Les 2 approches sont complémentaires et peuvent se combiner pour couvrir la totalité des cas d’invalidation à cibler.