Carnet Wiki

30. API Cachelab 2. Action globale ( dev )

Version 3 — 5 months ago JLuc

Alors que le premier niveau d’API est assez bien stabilisé, ce 2ème niveau d’API globale est susceptible de beaucoup évoluer. À terme, il devrait bénéficier de compléments pour automatiser le ciblage des invalidations, ou le paramétrer via un clic pour les sites simples.

Le niveau d’API globale intercepte les invalidations du cache quelque soit leur origine (code de SPIP ou des plugins), en surchargeant la fonction suivre_invalideur . CacheLab interprète alors le signal d’invalidation reçu et permet d’appliquer une stratégie d’invalidation ciblée spécifiquement pour ce signal.

Il y a un petit nombre de types de signaux d’invalidation. À chaque forme de signal est associé un typesignal :
-  Pour chaque type d’objet d’un site, il y a un signal d’invalidation de la forme id=“objet/id_objet”, qui est activé lorsqu’un crée, modifie ou détruit un objet de ce type. Par exemple id=“article/1234”. Par simplification on dit parfois aussi que le signal est alors “article/1234”. Dans cet exemple, le typesignal est article
-  Certains autres signaux correspondent à des événements plus qu’à des objets : recalcul lors d’une demande via var_mode=recalcul. Là, le typesignal est recalcul.
-  Certaines modifications d’objets génèrent un signal exotique : le signal favori/article/1234 indique qu’une invalidation est demandée pour cause de changement d’un favori portant sur l’article 1234. Dans le cas des favoris, un autre signal est également généré à la suite : favori/auteur/98 qui indique qu’un favori concernant l’auteur 98 a été créé, modifié ou supprimé. Dans cet exemple, le typesignal est favori

Rq : Les signaux d’invalidations ne sont pas utilisés dans le noyau de SPIP et ne servent que pour d’éventuels plugins comme CacheLab. Il n’est donc pas exclu que certains plugins provoquant des invalidations ne renseignent pas du tout ou pas correctement ce signal : dans ce cas il faudra les corriger pour qu’ils fournissent un signal suffisamment descriptif du motif et du contexte d’invalidation.

Pour mettre en oeuvre ce 2eme niveau d’API, le webmestre doit définir une stratégie d’invalidation pour chacun des types de signaux, au moyen d’une fonction dédiée dans laquelle il appellera les fonctions du 1er niveau : controler_invalideur et cachelab_cibler avec les paramètres $action='del' et avec les condition et options permettant d’invalider précisément les caches qui deviennent périmés.

Pour traiter le signal "typesignal/...", il faut définir une fonction cachelab_suivre_invalideur_typesignal ($signal, $modif).
Les arguments sont :
-  $signal : le signal reçu.
-  $modif : a priori c’est true.
La fonction renvoie true s’il faut ensuite poursuivre encore les traitements standards d’invalidation, ou false, si le signal a été entièrement traité et qu’il n’y a plus rien à faire.

En général pour un signal “unobjet/id_unobjet”, cette fonction appelera cachelab_cibler('del', array('objet'=>$objet, 'id_objet'=>$id_objet)); pour invalider tous les caches des squelettes ayant cet objet précis dans leur environnement. Il se peut, toutefois, que cela ne suffise pas, notamment lorsque cet objet peut figurer dans des listes : ces listes ne reçoivent pas les id des objets contenus mais des indications génériques (par exemple : “afficher 5 objets à partir du 10ème”).

Si les squelettes sont bien rangés, il se peut que les noisettes de “listes d’objet” soient rangées dans un dossier “liste”, et alors il sera possible d’appeler également :
cachelab_cibler('del', array('chemin'=>'liste'));. Et sinon, il faudra changer le rangement de vos squelettes pour pouvoir les facilement avec cachelab... par exemple en mettant vos listes dans un dossier “liste”.

Exemples :

// gérer une demande d'invalidation concernant un point GIS
function cachelab_suivre_invalideur_gis($cond, $modif) {
	include_spip ('inc/cachelab');
	cachelab_cibler('del', array ('chemin'=>'json_')); // cibler gis_json, gis_article, etc
}
// gérer une demande d'invalidation concernant un document
function cachelab_suivre_invalideur_document($cond, $modif) {
	include_spip ('inc/cachelab');
	cachelab_cibler('del', array ('chemin'=>'documents'));
}

Ce 2eme niveau d’API permet donc de mettre en place une stratégie d’invalidation plus globale : chaque fonction répond à un signal d’invalidation spécifique, mais pour tout le site et quelque soit l’origine de l’invalidation de cet objet, et non formulaire par formulaire.