macrosession : pistes de développements futurs

Pistes pour d’éventuels futurs développements

-  #_COOKIE{...} : pour récupérer la valeur d’un cookie en php et faire des traitements dessus (cf besoin de Tss : « Actuellement un script JS ajoute une classe sur un bloc selon le choix de l’utilisateur⋅ice, mais donc la classe n’est appliquée qu’une fois le dom chargé, et ça produit un espèce de flash pas très sympa. Alors je voudrais récupérer la valeur d’un cookie dans un squelette pour avoir la classe appliquée dès le départ dans le html, avant que le script se charge. »)

-  #_SWITCH #_CASE #_DEFAULT : définir ces balises permettant de faire comme le plugin switchcase mais en tant que macros. Imaginer avec une syntaxe sympa.
Rq : Cette envie née avec la découverte de l’outil d’internationalisation fluent de Mozilla : https://projectfluent.org/fluent/guide/ .

-   Dé-sessionner #URL_ACTION_AUTEUR autrement que par une inclusion sessionnée. Toutefois, il semple impossible d’utiliser une macro en argument d’un #BOUTON_ACTION. Donc, puisque c’est certainement le contexte d’appel le plus fréquent, peut être faut il plutôt créer une macro #_BOUTON_ACTION_AUTEUR qui intègre et rassemble les 2.

-  Syntaxe : dans SPIP, la syntaxe pour des éléments dynamiques (générant du PHP dans le cache) a souvent recours aux chevrons (<INCLURE> ou <BOUCLE_b()...>). Mais il y a aussi des exceptions (#FORMULAIRES).
Serait-il bien d’avoir une syntaxe avec des chevrons pour ces macros et de se passer du préfixe underscore ? Ou au contraire convenir que toute balise dynamique a un nom commençant par ’_’ ?

-  Une inclusion superdynamique : (Attention c’est technique) Les inclusions dynamiques inclues dans une inclusion statique sont dé-dynamisées (voir Les enseignements de XRay) . On pourrait toutefois créer une nouvelle sorte d’inclusion qui reste dynamique même lorsqu’elle est inclue dans une inclusion statique : une forme d’inclusions superdynamiques.
Syntaxe envisagées : <_INCLURE{}> (ou <<INCLURE{}>> si TOUTES les balises dynamiques en venaient à s’écrire avec des chevrons)

-  Une extension de #SESSION qui sessionne « normalement » le cache mais permette d’accéder aux champs étendus gérés par #_SESSION. Il arrive que ça soit utile, quand on a besoin de manipuler une valeur comme un objet SPIP et non comme un code PHP. On peut faire sans, mais ce serait un petit confort et de l’homogénéïté entre #SESSION et #_SESSION.

-  Optimisation : Calculer dès la compilation la fonction appelée pour un filtre, l’utiliser dans le code compilé, et du coup il n’y aura plus besoin d’inclure inc/filtres dans mes_options.

-  Signalement des erreurs : Étendre la détection par le compilateur des erreurs et leur signalement :

• pour les arguments calculés, il a fallu désactiver la détection d’erreur. En réintrodurie une nouvelle pour détecter les erreurs dans les arguments calculés, avant qu’elles ne se fassent.
• détection des mauvaises imbrications de SI SINON FIN et signalement proprement par une erreur.
• si possible : appels de filtres et parties conditionnelles avant / après : détection et refus des affichages conditionnels [ ( |filtre) ].

-  Cache des sessions étendues : Mettre à disposition un mécanisme simple pour cacher et rafraîchir les valeurs de session étendue (cf les notes sur microcache plus bas)

Pistes pour le cache des données étendues

Si l’accés ou le calcul des données étendues est coûteux, il faut le mettre en cache. C’est notamment le cas si l’accés se fait par une API sur un serveur externe.

recuperer_url_cache

Si les valeurs se font sur un serveur externe on peut simplement utiliser recuperer_url_cache qui met en cache SPIP le fichier récupéré.

Dans mes essais, la durée de l’accés est alors divisé par 100 ou 200 : on passe de environ 200 ms à 1ou 2 ms.

Attention : les caches abandonnés ne sont jamais effacés et la réserve peut augmenter ! Il faut penser à faire le ménage, ou implémenter un cron de nettoyage périodique des caches périmés.

microcache

Le microcache (produit par le plugin éponyme) est un fichier cache totalement statique, de longue durée et dont le nom est facilement accessible. Du fait que le nom est accessible, on peut en effacer un sélectivement.

-  Annonce sur seenthis
-  Sources sur la zone

Le filtre |microcache s’applique sur un id_auteur, et reçoit le nom de fichier d’un squelette en argument. Le squelette caché par microcache reçoit l’id_auteur dans #ENV{id}. On peut aussi appliquer |microcache sur une chaine qui sert d’identifiant alphanumérique.

microcache stocke sous forme de fichiers et n’est donc souvent pas plus efficace que memoization.
Mais microcache a une interface pratique pour le stockage de data visiteur étendues ou squelettes de visu = un filtre portant sur un id_auteur, que n’a pas memoization en l’état.

Le code de microcache est simple et peut facilement être dupliqué et adapté pour d’autres formes de stockage que sur le disque. On pourrait donc faire un plugin dupliquant l’interface filtre de microcache et stockant avec memoization.

Une autre différence, c’est que microcache enregistre de manière plus « définitive » sur le disque dur, avec l’avantage que ça tient entre les redémarrages et l’inconvénients que ça se remplit sans jamais se vider si on ne fait rien.

Selon Fil, ce serait mieux de faire évoluer memoization et d’abandonner microcache. Et donc ajouter à memoization une couche « filtre sur id_auteur ou identifiant string ».