Carnet Wiki

CacheLab étend la balise #CACHE

Version 8 — il y a 4 mois 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 même sans mémoization et sans cache APC activé (mais ça n’a pas été testé).

On peut donc activer CacheLab uniquement pour bénéficier des extensions de 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 :

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 2e 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 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’âce du cache, 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 de ses besoins, ainsi que le filtre d’affichage de la date apparié.

Loger des éléments du cache

#CACHE{log ...}&lt;/code <var>log&lt;/var > permet de loger des morceaux du cache, metadonnées et valeur vleuir  .
 
 
<code class='spip'>#CACHE{3600, log}&lt;/code filtre-log}&lt;/code > : loge tout le cache, méta et html ( et  spécifie  une  durée  de  3600s  pour  le  cache )
 &lt;code  class='spip'>#CACHE{log  
&lt; code  class='spip'>#CACHE{filtre-log  lastmodified}

 : loge l’entrée ’lastmodified’ du cache
<code class=’spip’>#CACHElog class=’spip’>#CACHEfiltre-log contexte : loge tout le tableau des variables environnement (#ENV)
<code class=’spip’>#CACHElog class=’spip’>#CACHEfiltre-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 < var > cachelab_</var > _.

Vérifier le sessionnement

assertsession

assertsession permet de vérifier l’état sessionné d’un cache donné : le cache est il sessionné ou non ? l’internaute est il identifié ou non ?

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). Le filtre assertsession 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 arguments possibles sont : oui, oui_anonyme non , oui_login login , non anonyme , anonyme log

-  session assert filtre-assertsession non}">#CACHE{3600, session assert filtre-assertsession non} s’assure que les emplois sont non-sessionnés
-  <code class=’spip’>#CACHEsession class=’spip’>#CACHEfiltre-assertsession oui s’assure que tous les emplois sont sessionnés
-  <code class=’spip’>#CACHEsession class=’spip’>#CACHEfiltre-assertsession login s’assure que tous les emplois sont sessionnés avec un internaute identifié
-  <code class=’spip’>#CACHEsession class=’spip’>#CACHEfiltre-assertsession anonyme s’assure que tous 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

Filtrage post-calcul d’un cache

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

Pour traiter une instruction #CACHE{macommande arg1 arg2}, le webmestre doit définir une fonction cachelab_filtre_macommande.
Un autre 2e argument est possible : filtre-unefonction. Cette La fonction
-  
< var>cachelab_filtre_unefonction</var > qui est appelée après le calcul du cache
-  
reçoit 2 arguments  :
-
le cache entier (toutes sa durée , le contexte et ses autres métadonnées et ainsi que le code compilé). ) et peut le modifier puis éventuellement mettre à jour la version mémoizée . Si cet argument est reçu par référence, la fonction peut le modifier puis éventuellement mettre à jour la version mémoizée.
- le reste de l’argument de #CACHE. Dans l’exemple ce sera arg1 arg2On peut également passer un paramètre constant. C’est un post-processing dont les possibilités sont encore inexplorées.

Rq :
-  avec

#FILTRE{unfiltre}&lt;/code>,  >  à  la  fin  d'un  squelette ,  la fonction unfiltre reçoit le code html de tout le squelette, comme un filtre SPIP habituel. 
-   avec  &lt; code  class='spip'>#CACHE  {filtre-unfiltre  arg}&lt;/code >  au  début  d'un  squelette ,  la  fonction  unfiltre  reçoit  non  le  HTML  mais  le  cache  entier  avec  ses  métadonnées  ( environnement ,  lastmodified ,  invalideurs ,  etc  et  parmi  elles ,  le  html )
 
 
Le webmestre peut définir lui même ses filtres à caches. 
Par exemple  <code  class='spip'>#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’. Éventuellement, le passage de $cache peut être fait par référence, ce qui permet que le filtre modifie son contenu.

2 filtres sont livrés d’origine avec le plugin : assertsession et log

- Une dernière valeur de l’argument n’induit pas une assertion mais systématiquement un log d’info :
#CACHEfiltre-assertsession log crée un log avec l’état de la session pour chaque instance du cache : oui_login pour un visiteur identifié dans un cache sessionné, oui_anonyme pour un visiteur anonyme dans un cache sessionné, non pour un cache non sessionné.

Attention : selon le jeu de squelette globalement, il se peut qu’un squelette soit inclu de manière statique à un endroit, et dynamique à un autre endroit, et il peut ainsi être employé à la fois de manière sessionnée et non sessionnées selon les circonstances. SPIP n’optimise pas ces subtilités et fournit des caches différents dans tous ces cas. Dans un tel cas, aucun assertsession n’est possible (sauf ’log’)

log

Voir aussi


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