Carnet Wiki

CacheLab étend la balise #CACHE

Version 14 — il y a 1 semaine JLuc

La balise

#CACHE

est étendue par CacheLab pour fournir de nouveaux services. Ces fonctionnalités peuvent être utilisées :
-  en complément aux autres fonctionnalités et API fournies par CacheLab
-  ou bien sans que les autres fonctionnalités de CacheLab soit utilisées
-  et, dans une certaine mesure , sauf exception même sans mémoization et sans cache APC activé ( il faudrait lister précisément ce qui est possible et contrairement à [l’API cachelab->5033] ce qui ne l’est pas ). , ces fonctionnalités ne nécessitent pas un cache APC sur le serveur. Certaines d’entre elles nécessitent que Memoization soit active, mais ce peut être avec la méthode filecache disponible sur tout serveur.

L’argument d’url var_cache, utile pour le debuging et fourni par le plugin, est également fonctionnel sans memoization : c’est pour cela qu’on le présente sur cette page.

On peut donc activer CacheLab uniquement pour bénéficier des extensions de < var>var_cache</var > ou la balise

#CACHE

, sans que ça impacte le site par ailleurs.Les nouveaux paramètres s’ajoutent avec le fonctionnement fourni par le core et peuvent s’y combiner :

Sauf exception, ces fonctionnalités ne nécessitent pas un cache APC sur le serveur. Certaines d’entre elles nécessitent tout de même que Memoization soit active, mais ce peut être avec la méthode filecache.

Cache de durée dynamique et contextuelle

Dans le core, la durée de cache spécifiée par #CACHE sert quand c’est , mais quand elle n’et pas nulle, elle sert rarement puisque l’ensemble de tous les caches 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 les invalidations voulues, alors il n’y a pas d’invalidations prématurées, et la durée indiquée pour le cache peut réellement servir. 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 :

#CACHE{duree methode unenv}


-  methode aprés duree indique quelle méthode sera utilisée pour calculer la durée du cache : c’est la fonction

cachelab_duree_methode

qui sera appelée. C’est elle que le webmestre doit définir et coder pour calculer dynamiquement la durée en fonction d’une des variables d’environnement.
-  unenv est le nom d’une des variables de l’environnement du cache. Souvent, ce sera un champ SQL de l’objet principal affiché par le squelette, avec un format DATE ou DATETIME. Par défaut, c’est date_creation. Cette valeur sera transmise en argument à la fonction

cachelab_duree_methode

.

Exemple :

#CACHE{1200,duree-progapprox date_publication}

 : le cache aura une durée progressive approximative calculée par la fonction cachelab_duree_progapprox à partir de la date de publication. La valeur 1200 servira seulement si on désactive le plugin CACHELAB.

Une méthode de calcul de durée 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’âge de l’objet affiché, jusqu’à valoir 6 mois pour les objets de plus de 2 ans.

Si cette méthode ne convient pas, il appartient au webmestre de coder la fonction qui implémente la méthode dont il a besoin.

Rq : L’usage de l’argument duree nécessite Memoization.

Loger des éléments du cache

#CACHE{log ...}

permet de loger des morceaux du cache, metadonnées et valeur .

#CACHE{3600, log}

 : loge tout le cache, méta et html (et cet exemple spécifie aussi une durée de 3600s pour le cache)

#CACHE{log lastmodified}

 : loge l’entrée ’lastmodified’ du cache

#CACHE{log contexte}

 : loge tout le tableau des variables environnement (#ENV)

#CACHE{log contexte/date_creation}

 : loge l’entrée ’date_creation’ de l’environnement

Le nom du fichier de cache utilisé pour ces logs est le nom du chemin du squelette, dans lequel les / ont été remplacés par des _, et préfixé par cachelab_

Vérifier le sessionnement

La bonne conception d’un squelette dans lequel l’internaute peut s’identifier suppose de parfaitement savoir si un squelette est sessionné ou non pour éviter d’exploser les caches sessionnés. La méthode session permet de s’assurer que le squelette se comporte bien comme on l’a conçu, et que ce comportement perdure lors des évolutions futures de ce squelette ou d’autres parties du jeu de squelette.

Les valeurs possibles du sessionnement sont : oui, oui_anonyme, oui_login, non, anonyme.

On vérifie que le sessionnement est conforme avec session assert :

-  

#CACHE{3600, session assert non}

s’assure que les emplois sont non-sessionnés
-  

#CACHE{session assert oui}

s’assure que les emplois sont sessionnés
-  

#CACHE{session assert oui_login}&lt;/code login}&lt;/code >  s'assure que les emplois sont sessionnés avec un internaute identifié
- <code class='spip'>#CACHE{session assert anonyme}

s’assure que les emplois sont non sessionnés ou sans internaute identifié

Dans le cas où une assertion n’est pas vérifié, une erreur est logée dans le fichier cachelab_assertsession

La méthode session accepte d’autres arguments utiles le temps d’une mise au point :
-  <code class=’spip’>#CACHEsession echo</code var>echo</var > : l’état du sessionnement est affiché à l’écran au moment du calcul du cache
-  <code class=’spip’>#CACHEsession log</code var>log</var > : l’état du sessionnement est logé dans le fichier de logs cachelab dédié à ce squelette
-  
< var>insert</var >  : le code qui affiche l’état du sessionnement est inséré à la fin du contenu HTML du cache . Le résultat est similaire à

#CACHE{log invalideurs/session}

.
-

#CACHE{session insert}

 : le code qui affiche l’état du sessionnement est inséré à la fin du contenu HTML du cache. Il s’affichera donc chaque fois qu’on affiche ce cache. (todo : mieux tester)

Rq : L’usage de l’argument session insert nécessite Memoization.

Filtrage post-calcul d’un cache

Il est possible pour le webmestre de définir d’autres méthodes de filtrages du cache.

Pour traiter une instruction

#CACHE{macommande arg1 arg2}

, le webmestre doit définir une fonction cachelab_filtre_macommande. Cette fonction :

  • est appelée après le calcul du cache
  • reçoit 2 arguments :
    - le cache entier (métadonnées et code compilé). Si cet argument est reçu par référence, la fonction peut le modifier et demander de mettre à jour la version mémoizée.
    - le reste de l’argument de #CACHE. Dans l’exemple ce sera arg1 arg2
  • renvoie un booléen :
    - true si l’argument $cache est passé par référence et a été modifié. Cachelab se chargera alors d’actualiser le cache ( et pour cela il faut que Memoization soit actif ).
    la mémoïzation .
    - false sinon.

Le webmestre peut ainsi définir lui même ses filtres à caches. Par exemple

#CACHE{1200,filtre-bidouille grave}

appelle, aprés chaque calcul et enregistrement d’un cache, la fonction

cachelab_filtre_bidouille

avec 2 arguments : le $cache et l’argument $arg valant ’grave’.

Rq Rq :
-  2 filtres de cache sont livrés d’origine avec le plugin : session et log, décrits plus haut. Leur code peut servir d’exemple pour en coder d’autres.
-  La fonctionnalité #FILTRE de SPIP (usage :

#FILTRE{unfiltre}

) est différente puisqu’elle porte sur le contenu HTML, alors que les filtres de cache portent sur le cache entier, contenu HTML et métadonnées. Cependant, une fonctionnalité similaire à celle de #FILTRE pourrait être obtenue par un filtre sur le cache.
-  Actuellement, #CACHE  :#CACHE ne peut pas recevoir plusieurs arguments de type ’filtre’, mais un seul. On ne peut donc pas combiner un log, un assert et un filtre maison. Pour l’instant soit tant pis le webmestre fait son choix, soit il définit un filtre maison qui fait la combinaison désirée.

var_cache=oui

La variable d’environnement < var>var_cache</var >, var_cache , lorsqu’elle est présente dans l’url, permet d’afficher des informations sur les caches générés pour chaque noisette incluse dynamiquement dans la page :
-  l’état de sessionnement (comme avec

#CACHE{session log}

)
-  la durée du cache lorsqu’elle a été calculée par une méthode dynamique

Rq : Actuellement, seules les informations des caches des inclusions dynamiques sont visualisées.

Voir aussi

-  Compléments CacheLab et todo
-  XRay, un explorateur de cache
-  CacheLab étend la balise #CACHE
-  Plugin ’macrosession’ : usage optimisé et extension des données de session