Tontof

Décidément je ne suis pas des plus réguliers. Il ne s'en fallait pas de beaucoup pour qu'il n'y ait pas de message de ma part en 2025 !

Pour bien finir l'année, je vais tenter une prédiction. Pour les 14 ans de Tontof en ligne, je vais essayer de publier une nouvelle version de KrISS feed. Il y a quelques temps... plus d'un an et demi j'avais écris : « J'ai même pensé mettre à jour KrISS feed en utilisant ce principe, un jour peut-être... »

Et ce jour va sûrement arrivé en 2026. J'ai une version presque fonctionnelle et je pense être arrivé à ce que j'ai toujours espéré. J'avais fait une première tentative avec KrISS mvvm en suivant les concepts de programmation orientée objet (POO) et les infos de Tom Butler. Dans le fond ce n'était pas si mal mais après avoir découvert dispatch, je voulais plus simplement me limiter à de la programmation fonctionnelle. C'est sûr que c'est à contre-courant de toutes les tendances actuelles mais dans l'esprit je veux allier mes connaissances de la POO et l'usage de Symfony avec une approche plus fonctionnelle. J'ai commencé en présentant quelques codes comme KrISS aaaa et KrISS json.

Voici donc quelques infos sur ce que sera la nouvelle version de KrISS feed :
- toujours un seul et unique fichier index.php aussi léger que l'ancienne version avec un objectif situé autour de 300ko (Je suis actuellement à 284ko sans avoir cherché à trop optimiser mais il me manque encore l'installation, l'authentification et la partie javascript)
- le plus générique et personnalisable possible (La plupart du code sera basé sur KrISS aaaa ; actuellement le code spécifique à KrISS feed fait 42ko)
- un graphisme plus moderne avec la gestion de thème clair/sombre : c'était un reproche récurrent de l'ancienne version (Pour cela j'ai utilisé PicoCSS qui fait 83ko et qui est compté dans les 284ko pour dire à quel point ce sera plus petit que l'ancienne version)
- plein de concepts chouettes (l'usage de JSON schema pour définir les modèles, l'approche de Transphporm pour la gestion des modèles html, une traduction plus moderne que gettext avec ICU unicode Message Format, une inspiration de MongoDB pour les données, la génération de formulaire avec une approche inspirée de Symfony Forms, etc.)
- une réduction des dépendances, il n'y en avait déjà presque pas mais c'est encore moins (plus de libxml qui posait de nombreux problèmes, j'ai simplement adapté un code de Bohwaz qui semble très bien faire le job !)
- l'arrêt de la publication de code sur Github. Cela fait un moment que je me fais la réflexion de trouver une alternative et je crois bien que je commencerai avec cette nouvelle version en utilisant tout simplement la gestion de code git sur o2switch. À voir comment cela peut s'intégrer avec des personnes qui veulent contribuer.
- garantie sans IA, je n'ai encore jamais rien demandé à ChatGPT ou autre, je ne pense pas que ça changera en 2026.

Sur le papier c'est presque tout mieux qu'avant mais il y a quand même un petit point négatif par rapport à l'ancienne version. La généricité du code va rendre le code un peu moins efficace. Là où l'ancienne version affichait une génération de la page principale en quelques dizaines de millisecondes pour plus de 100 flux, la nouvelle version mettra quelques centaines de millisecondes. Pas vraiment perceptible en soi mais c'est un point qu'il est quand même important de relever ! J'essayerai en tout cas de faire du mieux que je peux pour limiter la perte de performance (je rappelle que je travaille sur un RPI 400 donc ce critère reste très important pour moi)

Et pour finir avec une petite cerise sur la gâteau, un petit aperçu de la future version de KrISS feed avec les flux de Tontof et de Sebsauvage qui reste sans nul doute la personne que je suis qui publie le plus régulièrement et dont je ne me lasse toujours pas de lire le contenu.

Bonne exploration de la future version de KrISS feed (je n'ai pas encore géré l'interface mobile :-)

Et parce qu'il y a quelques fonctionnalités qui ne sont pas encore directement accessibles :
- une version fr: https://tontof.net/feed?_locale=fr
- des données en format json: https://tontof.net/feed?_format=json
- des filtres basés sur MongoDB : https://tontof.net/feed/?items[filter][status]=read

D'ici la publication de la nouvelle version de KrISS feed je détaillerai certains points de KrISS aaaa avec par exemple la mise en place de la traduction ainsi que la gestion des modèles html.

Bonne fin d'année 2025 et j'espère à très vite !

Pour cet anniversaire je n'ai pas de nouveau code à publier mais un inventaire personnel que je voulais partager.

Je vous ai dit que j'étais un grand utilisateur d'emacs et j'ai même partagé ma configuration .emacs.d mais c'est officiel, je suis en train du passer du coté obscur et si je développe encore professionnellement avec emacs, je développe personnellement avec vim et j'envisage une conversion totale dans les semaines/mois qui arrivent. Je n'ai pas encore de configuration vim à partager parce que je suis en train d'étudier maintenant le passage à neovim mais quand ça sera fait, je la partagerai aussi. Je connaissais déjà un peu vim mais si j'ai une série de vidéos à vous conseiller pour débuter c'est la playlist de ThePrimeAgen que j'ai trouvé assez concise et complète et qui se termine aussi avec le passage à neovim...

Pour l'instant je ne pourrais pas complètement quitter emacs parce qu'orgmode n'étant pas entièrement supporté par vim il va falloir que j'étudie comment mettre à jour KrISS tuto

Si vous vous demandez pourquoi un tel changement, la réponse est simple l'efficacité. Attention, je ne parle pas ici d'efficacité liée à une quelconque rentabilité. C'est juste que j'essaye d'être de plus en plus sobre et qu'en pratique cela veut dire que j'ai remplacé mon ordinateur portable qui est en train de mourir par un RPI400. Si la différence de chargement d'un fichier entre emacs et vim sur mon ordinateur portable n'était que peu perceptible, vous n'imaginez pas à quel point il n'y a pas photo sur mon RPI400. Je ne savais pas trop si un tel support me permettrait de travailler dans de bonnes conditions mais après plus de 2 ans, je ne reviendrai pas en arrière. C'est vrai que l'installation est un peu plus compliquée en mode nomade parce qu'il y a plusieurs cables à brancher (alimentation, souris, écran (x3 pour mon écran portable Arzopa : cable d'alimentation usb-c sur la prise, cable usb-c/usb le RPI400 et cable hdmi), mais au quotidien il est posé sur un bureau branché et il n'y a donc qu'à brancher la prise d'alimentation au lieu d'appuyer sur un bouton de démarrage (d'ailleurs c'est même plus simple parce que mon RPI400 s'allume tout seul en branchant la prise contrairement à mon ordinateur pour lequel je branche la prise et j'appuye sur le bouton).

Pourquoi un RPI400 ?
- Pas de batterie (oui c'est un critère parce qu'en pratique je n'ai que très peu utilisé mon ordinateur portable sans fil et que la batterie avec le temps ne joue plus du tout son rôle).
- Pas cher (ce n'est pas vraiment le critère que je mets en premier parce que ça ne me dérange pas vraiment d'acheter un outil un peu plus cher s'il dure longtemps. Mon ordi a 9 ans et j'espère bien l'utiliser encore plusieurs années avec le ventilateur bruyant et le tour de l'écran recollé à la fibre de verre).
- Plus sécurisant (je transporte moins d'informations personnelles et/ou sensibles avec mon RPI400 qu'avec mon ordi. Je pourrais crypter mon disque dur mais j'ai préféré opter pour une clé USB avec LUKS que je trouve plus pratique à l'usage surtout quand on utilise différents outils (ordinateurs portables perso et non perso, RPI400, etc.) on retrouve tout ce dont on a besoin sur la clé). Merci Sebsauvage pour la découverte.

Au quotidien, je n'ai pas beaucoup de reproche à faire à mon RPI400 si ce n'est qu'il est parfois un peu limite sur certains sites web mais dans ce cas j'en veux plus au site web qu'à mon RPI400. Je n'imagine même pas comment se passerait l'ouverture du menu windows 11 dessus :-)

Et pour terminer, j'envisage un apprentissage du clavier Ergo-l. Merci Orangine Rouge pour le partage. J'ai tenté il y a plusieurs années le passage à bépo (clavier adapté à l'écriture en français) et contrairement à d'autres personnes :-p j'avoue ne pas avoir vraiment insisté. Comme je regrette un peu, je me dis que c'est l'occasion de se remettre à un apprentissage qui peut être enrichissant. Ergo-l étant adapté au français, à l'anglais et au code, je me dis que c'est l'occasion ou jamais parce que c'est clairement ce que j'utilise le plus et qu'au final le bépo n'aurait pas été le plus adapté. Comme je ne regarde déjà pas le clavier je me dis que je devrais pouvoir y arriver assez facilement et ça me permettra peut-être de perdre certains défauts de frappe...

À suivre

11e et dernier bout de code de la série que j'avais promis pratiquement l'année passée pour les 11 ans de tontof.net. C'est promis je ne ferai plus de promesse que je ne pourrais pas tenir... Euh... Ça commence mal ? En tout cas, j'avoue que je n'avais pas imaginé que cela m'aurait pris autant de temps pour publier tous ces bouts de code.

Pour terminer la série voici donc KrISS paol un petit outil qui permet d'exploiter le système PAO pour retenir des suites de chiffres. PAO c'est pour Personne, Action et Objet et PAOL c'est avec un Lieu en plus. Des explications sont données sur la page consacrée au projet, je ne vais donc pas m'étendre sur le projet mais plutôt sur les données qui avec votre aide pourrait grandement s'améliorer.

Dans l'idée si vous devez retenir les décimales de π : 3.141592653, au lieu de les retenir directement vous apprenez la phrase : Dorothée loue une péniche à Limoux et avec la traduction du code chiffres - sons vous retrouvez les décimales ! Ça permet aussi de retenir des numéros de téléphone ou des codes pour certains accès (je m'en suis servi pour le code d'une imprimante que j'utilisais ponctuellement et après presque un an sans l'avoir utilisé, j'avais oublié le code mais pas la phrase qui m'a permis de le retrouver facilement !).

Actuellement, c'est déjà fonctionnel mais j'aimerais pouvoir améliorer les données pour avoir encore plus de choix dans les phrases proposées. Ce qu'il faut savoir c'est que la partie la plus délicate est la traduction d'un mot en phonétique pour ensuite le traduire en chiffres. Pour limiter certaines erreurs j'ai supprimé les mots qui avaient 2 prononciations différentes dans le wiktionary. Il y a donc des mots qui sont supprimés, comme par exemple le prénom Jean qui correspond à 6 mais qui peut aussi se prononcer DJean pour le vêtement et qui dans ce cas correspondrait à 16. Pour "Jean/jean", on pourrait faire la différence s'il s'agit d'une personne ou d'un objet mais à partir des données que j'ai pu extraire je n'ai pas vraiment pu gérer ce genre d'exception et "Jean/jean" ne sont donc pas proposés.

Pour la liste des personnes, j'ai utilisé les données de l'INSEE pour utiliser les prénoms français donnés entre 1900 et 2021 (les propositions sont ordonnées par fréquence d'apparition). Pour améliorer cette liste, une liste de personnalités/personnages seraient un plus, mais je n'ai pas trouvé de listes suffisamment fournie et intéressante pour pouvoir l'intégrer.
Plus de détails : https://github.com/tontof/kriss_paol/blob/main/data/person/script.bash

Pour les actions, j'ai trouvé une liste de verbes conjugués et je n'ai gardé que les temps présent et futur qui ont une prononciation différente. (Certains systèmes PAO utilisent seulement la traduction du verbe à l'infinitif, j'ai préféré prendre le son du verbe dans la phrase finale).
Plus de détails : https://github.com/tontof/kriss_paol/blob/main/data/action/script.bash

Pour les objets, c'est une donnée assez difficile à trouver et je suis donc parti d'une liste de noms assez générique. Le résultat n'est pas trop mal mais peut sûrement être amélioré.
Plus de détails : https://github.com/tontof/kriss_paol/blob/main/data/object/script.bash

Enfin pour les lieux, c'est encore sur l'INSEE que j'ai récupéré les communes de France. Mais là encore, il serait intéressant de pouvoir ajouter d'autres localités comme les villes assez connues d'autres pays (Londres, etc.), des noms de pays (Italie, etc.), des lieux précis (la tour Eiffel, etc.).
Plus de détails : https://github.com/tontof/kriss_paol/blob/main/data/location/script.bash

Tout est sur Github pour les infos un peu plus techniques mais si vous avez des pistes d'améliorations je suis preneur !

Avant dernier bout de code avant le 11e prévu mardi prochain \o/

execCommand combiné à contenteditable est super pratique pour éditer une page html même s'il génère un code HTML un peu nul (par exemple les balises <i> ou <b> pour l'italique et le gras). Maintenant le problème ne se pose plus car l'usage de execCommand est devenu obsolète.

À ma connaissance il n'y a aucune alternative à execCommand et s'il existe des éditeurs HTML sympathiques, j'aimais bien ContentTools qui semble abandonné, j'avais envie d'étudier comment fonctionnaient les sélections en javascript et j'ai donc commencé KrISS ecmd.

C'est encore loin d'être complet, mais j'ai réussi à gérer plusieurs problèmes qui se posaient sur les sélections qui ne correspondaient pas toujours à ce que j'imaginais (quand on sélectionne du texte qui est dans une balise html, ça peut sélectionner le texte à l'intérieur dans les balises mais aussi le texte avec les balises) ainsi que sur la qualité du code HTML généré avec entre autres la fusion de même balises pour éviter la duplication de code (quand on veut mettre en gras du texte à côté de texte en gras, ça fusionne les 2 balises de gras).

L'objectif final de ce code serait de l'utiliser dans un projet de création de pages HTML statiques dans l'esprit de mobirise mais en plus simple, un KrISS edit ? En attendant le code est disponible sur Github.

J'étais un peu trop à la bourre pour publier du code mardi et puis j'ai appris par hasard qu'aujourd'hui 4 avril était une fête un peu spéciale car pour ce que ça vaut, c'est la Saint Isidore de Séville le patron des internautes, des informaticiennes et informaticiens... En tout cas je m'en sers d'excuse pour publier KrISS klok aujoud'hui !

L'idée vient du « puzzle chess » qui adapte les horloges des jeux d'échecs aux puzzles et qui permet de les aborder d'une façon bien différente de ce qu'on a l'habitude de faire avec. Voici une vidéo de présentation.

KrISS klok est encore bien loin de ce que j'ai en tête, mais j'essaye de publier même en l'état : « Not perfect, just good enough »

En tout cas c'est fonctionnel même si grandement imparfait. Comme à mon habitude je n'ai pas vraiment passé du temps sur le graphisme et je suis allé à l'essentiel de la fonctionnalité de base. Contrairement aux horloges d'échecs classiques, KrISS klok offre la possibilité d'avoir plus de 2 horloges, l'idée finale étant de pouvoir découper l'espace de façon plus agréable pour qu'on puisse l'adapter en fonction de la position des personnes autour de l'écran. J'aimerais pouvoir utiliser un diagrame de Voronoï en pondérant les points pour avoir des zones de tailles plus ou moins égales.

J'ai voulu utiliser des ServiceWorker pour le rendre accessible hors ligne, mais comme il s'agit d'une simple page html, le charger dans le navigateur ou l'enregistrer en local permet aussi de s'en servir directement sans trop de complication, je verrai donc plus tard pour améliorer cette partie là.

Il faudrait aussi qu'on puisse l'inverser en mode chronomètre plutôt que décompte. Une chose est sûre, ce ne sont pas les idées qui manquent pour l'améliorer. Le code est dispo sur Github en attendant que je trouve le temps de voir comment je peux faire avec mon hébergement pour gérer les git de mon côté.

Bon puzzle chess avec KrISS klok !

L'idée de Tom Butler pour la génération des pages PHP est vraiment originale. Son implémentation avec Transphporm montre une approche différente des autres projets plus classiques comme Twig. À ma connaissance c'est vraiment le seul projet qui utilise cette idée et théoriquement c'est très élégant dans le monde de la programmation object.

Pour mon approche plus impérative avec KrISS aaaa, j'ai imaginé l'utilisation d'un tableau associatif pour manipuler le code html à générer. Pour cela j'ai donc fait plusieurs fonctions pour transformer du code html en tableau associatif et vice versa.

En pratique, ça donne :
<?php include('src/helpers/html/html.php');

$string = '
<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="utf-8">
    <title>Title</title>
  </head>
  <body>
    body
  </body>
</html>
';
$array = html_to_array($string);
var_dump(array_to_html($array));
$arraySimplified = array_html_simplify($array);
$arraySimplified['html']['head']['title'] = "New title";
$arraySimplified['html']['body'] = [["p" => "new body"]];
$arraySimplified['html']['body'][] = ["p" => "add body"];
var_dump($arraySimplified);
var_dump(array_to_html($arraySimplified)); ?>



Ce qui donne comme résultat :
string(110) "<!DOCTYPE html><html lang="en"><head><meta charset="utf-8"><title>Title</title></head><body>body</body></html>"
array(2) {
  '!DOCTYPE' =>
  array(1) {
    '@' =>
    array(1) {
      [0] =>
      string(4) "html"
    }
  }
  'html' =>
  array(3) {
    '@' =>
    array(1) {
      'lang' =>
      string(2) "en"
    }
    'head' =>
    array(2) {
      'meta' =>
      array(1) {
        '@' =>
        array(1) {
          'charset' =>
          string(5) "utf-8"
        }
      }
      'title' =>
      string(9) "New title"
    }
    'body' =>
    array(2) {
      [0] =>
      array(1) {
        'p' =>
        string(8) "new body"
      }
      [1] =>
      array(1) {
        'p' =>
        string(8) "add body"
      }
    }
  }
}
string(140) "<!DOCTYPE html><html lang="en"><head><meta charset="utf-8"><title>New title</title></head><body><p>new body</p><p>add body</p></body></html>"



Une remarque importante, cela ne génère pas de code html avec des retours à la ligne et des indentations mais c'est un choix volontaire. Bien sûr cela peut poser problème avec les affichages inline-block qui ne réagissent pas exactement de la même façon s'il y a des espaces entre les balises ou non.

Le but étant de rester minimaliste, ce comportement est donc voulu !
It's not a bug it's a feature!

Quand dans le dernier article j'ai écrit que je ne pourrais pas garder le rythme des publications, je pensais que je reprendrais tranquillement à l'automne mais force est de constater que c'est avec le printemps qui arrive que je vais pouvoir reprendre la publication de code.

C'est plus ou moins vrai avec KrISS turn qui est un peu un entre 2. J'ai écrit plusieurs fois à blasten pour savoir si je pouvais publier mes modifications à son projet turn.js mais mes messages sont restés sans réponse. Sur github son projet semble abandonné à la version 4 mais sur son site, il y a une version 5 qui est bien plus aboutie même si la démo qui affiche des pages en html n'est pas forcément très convainquante : http://turnjs.com/catalog/

J'ai donc apporté quelques modifications afin de pouvoir faire un lecteur PDF en intégrant la bibliothèque Mozilla PDF.js. Je n'ai pas modifié la bibliothèque turn.js, juste quelques lignes de son script principal qui utilise sa bibliothèque.

Comme je n'ai pas eu de réponse, je ne publie pas sur github mais en regardant le code source il est assez facile de récupérer ce qu'il faut pour pouvoir héberger votre propre lecteur PDF sous forme de magazine.

Voici quelques exemples :
- https://tontof.net/turn/
- https://tontof.net/turn/?pdf=assets/pdf/classes.pdf
- https://tontof.net/turn/?pdf=assets/pdf/turnjs4-api-docs.pdf

J'ai 1 mois pour publier les 4 derniers projets, j'espère que je vais tenir le rythme !

Nous voilà à la moitié des présentations des codes (06/11 coïncidence je ne crois pas) et si j'ai réussi à garder à peu près le rythme depuis mon retour en ligne, je sens qu'avec l'été qui arrive, cela va être plus compliqué et je ne pense pas que je pourrais garder ce rythme. Il me reste 1 ou 2 projets à peu près présentables mais il y a encore un peu de boulot pour les derniers. Donc, pas d'inquiétude si je suis plus discret les prochaines semaines !

Je vous ai déjà parlé avec KrISS tuto d'un petit cours sur la compression de données où je présente les algorithmes classiques de compression sans perte (Huffman, Huffman adaptatif, le codage arithmétique, rle, lz77, lz78, lzw).

Pour la partie pratique, j'ai eu du mal à trouver des algorithmes qui fonctionnaient bien et qui permettaient d'illustrer ce que je montrais en cours. J'ai utilisé un temps https://sourceforge.net/projects/compressions/ mais la compilation n'était pas toujours simple et j'ai donc cherché des versions python que j'ai regroupé dans KrIIS lldc. C'est vraiment à but pédagogique et je ne vous invite pas à utiliser ce code pour compresser de vrais fichiers ! Personnellement je ne le ferai pas.

J'ai uniformisé l'usage des algorithmes et ajouté un petit bout de code pour le codage binaire du résultat. Les ordinateurs stockent l'information avec des octets (8 bits) mais quand on a besoin de stocker un nombre de bits précis qui n'est pas multiple de 8 c'est un peu compliqué, il faut trouver une méthode pour arriver à relire le résultat. J'imagine qu'il y a une solution existante mais je n'ai pas vraiment cherché et je me suis dit qu'il suffisait d'utiliser les 3 derniers bits d'un octet pour savoir combien de bits sont à supprimer.

"0": "00000100"
"1": "10000100",
"01": "01000011",
"010": "01000010",
"0110": "01100001",
"01110": "01110000",
"011110": "0111100000000111",
"0111110": "0111110000000110",
"01111110": "0111111000000101",
"011111110": "0111111100000100"

Il suffit de prendre les 3 derniers bits par exemple pour "0111110000000110" on a "110" ce qui donne 6 en décimal. On supprime donc les 3+6 derniers bits et on retrouve "0111110" qu'on voulait stocker à l'origine.

Je vous ai dit que j'avais exploré la programmation fonctionnelle avec KrISS aaaa : middleware et il y a quelques années j'ai voulu testé cette même approche pour l'utilisation de schémas json https://json-schema.org

Le résultat final est plutôt chouette :

tests suite:	nb tests	nb files

draft3: 	  520/520	    35/35

draft4: 	  735/735	    38/38

draft6: 	  995/995	    48/48

draft7: 	1286/1286	    57/57

draft2019-09: 	1571/1651	    59/68

draft2020-12: 	1579/1677	    58/68

draft-next: 	1623/1724	    58/68

C'était il y a quelques temps et j'ai dû faire 2/3 modifications pour valider les mises à jours des tests fournis par https://github.com/json-schema-org/JSON-Schema-Test-Suite pour continuer à valider les premiers drafts comme à l'époque où j'avais codé ça.

S'il n'y a qu'un seul fichier à regarder c'est la validation des URI/IRI à partir de la RFC
https://github.com/tontof/kriss_json/blob/main/schema/core/inc/rfc.php

Les validations proposées par PHP ne fonctionnaient pas pour tous les tests, j'ai donc dû lire un peu les RFC pour arriver à la validation de tous les tests. C'est à faire au moins une fois dans sa vie...

Pour valider un schéma json, il suffit d'inclure le fichier "json.php" et d'appeler la fonction "json_schema"

<?php 
include_once(__DIR__ . '/schema/json.php');

$json = 'https://json-schema.org/learn/examples/address.schema.json';
$address = file_get_contents($json);

$data = '
{
  "locality":"locality",
  "region":"region"
}
';
var_dump(json_schema(json_decode($address), json_decode($data)));

$data = '
{
  "locality":"locality",
  "region":"region",
  "country-name":"country-name"
}
';
var_dump(json_schema(json_decode($address), json_decode($data)));

$data = '
{
  "locality":"locality",
  "region":"region",
  "country-name":"country-name",
  "post-office-box":"post-office-box"
}
';
var_dump(json_schema(json_decode($address), json_decode($data)));

$data = '
{
  "locality":"locality",
  "region":"region",
  "country-name":"country-name",
  "post-office-box":"post-office-box",
  "street-address":"street-address"
}
';
var_dump(json_schema(json_decode($address), json_decode($data)));
 ?>

Ce qui donne comme attendu :

bool(false)

bool(true)

bool(false)

bool(true)

En pratique, je vous invite à utiliser une approche plus classique https://json-schema.org/implementations.html#validator-php mais KrISS json reste intéressant de par son approche fonctionnelle

La semaine passée était bien chargée et je n'ai pas eu le temps de partager un peu de code. Cette semaine, c'est un début de présentation d'un projet encore en cours. À l'image de KrISS MVVM qui est une sorte de projet générique pour développer rapidement des petites applications en utlisant la programmation orientée objet, KrISS aaaa a le même but mais avec l'esprit programmation fonctionnelle. À l'heure où j'écris ces lignes KrISS aaaa n'est pas vraiment opérationnel mais j'ai déjà quelques briques que je vais présenter petit à petit après avoir mis en place quelques tests pour présenter comment tout cela fonctionne.

La programmation fonctionnelle n'a plus vraiment le vent en poupe mais je pense qu'elle peut être intéressante car plus facile à comprendre que la programmation orientée objet et j'espère donc trouvé du temps pour concrétiser tout ça. J'ai même pensé mettre à jour KrISS feed en utilisant ce principe, un jour peut-être...

Voici donc une première présentation de middleware qui correspond au principe de la couche d'oignon illustré dans cet article : http://esbenp.github.io/2015/07/31/implementing-before-after-middleware/ mais en programmation fonctionnelle :

<?php include('src/helpers/middleware/middleware.php');

function before($object, $next) {
    $object[] = 'before';
    return $next($object);
}

function after($object, $next) {
    $object = $next($object);
    $object[] = 'after';
    return $object;
}

function core($object) {
    $object[] = 'core';
    return $object;
}

$middleware = middleware(['after', 'before', 'after', 'before'], 'core');

var_dump($middleware());
 ?>

Le résultat est le suivant

array(5) {
[0] =>
string(6) "before"
[1] =>
string(6) "before"
[2] =>
string(4) "core"
[3] =>
string(5) "after"
[4] =>
string(5) "after"
}

J'imagine utilisé ce principe de middleware pour gérer des plugins dans KrISS aaaa. Plus d'exemples dans le fichier de tests : https://github.com/KrISS/aaaa/blob/main/tests/MiddlewareTest.php