Extensibilité des codes yacs

Hellow Christophe,
merci pour cette initiative, c'est un chantier que je trouve important.
Shared/Codes.php est trop volumineux ( 4500 lignes ) et dissuade actuellement l'implémentation de nouveaux codes ou varations sur les codes, pourtant très demandés.

Ensemble de remarques sur ta propostion :

c'est assez simple, en touchant à peine à l'existant

J'aurais quand même vu plus loin avec un éclatement de codes.php. Toutes les familles de codes seraient regroupées par fichier à l'image de ton "plugin"
l'immense tableau (expression régulières/fonctions appelées) serait sorti de codes.php et construit à la volée.

Néanmoins à fin d'optimiser les performances, plutôt que de parcourir les fichiers à chaque fois, la construction dudit tableau pourrait être mis en cache, tout comme i18n transforme les .mo en .mo.php
Ce fichier-cache serait construit automatiquement, à voir quand (hook setup, premier appel d'un code...)
Si c'est nécessaire on peut optimiser davantage en mémorisant quelque part (values?) les codes les plus usités par le serveur de manière à les mettres en premier dans la construction du tableau.

Je suis un peu chagriné par le terme et l'aborescence "plugins". Tu as d'autres idées de plugins ? et nous avons déjà un "included".
Enfin en tout cas comme il s'agirait d'éclater codes.php, je propose la chose suivante :

nous avons déjà un répertoire codes/, qui contient en fait les pages d'exemples de codes yacs (d'ailleurs pas forcément à jour)
chaque fichier, en plus d'être une page de doc en ligne, condiendrait la déclaration d'une classe Mon_code extends codeyacs avec en méthode

• la déclatation des expressions régulières captées
• la fonction de traitement render associé

En procédant ainsi, on favoriserait la mise à jour de la doc en ligne à mesure qu'on ajoute des codes, et cela donne une arborescence plus logique. (Il est possible que les pages actuelles soient elles aussi éclatées)

A+

Christophe Battarel :

d'accord pour réserver included aux scripts de projets externes.

Selon ton idée de plugin on devrait alors avoir plugins/layouts, plugins/overlays, plugins/hooks, etc.

mais je trouve qu'on s'écarte du fonctionnement de yacs. Une grande différence de yacs avec d'autres CMS est qu'il n'y a pas un seul script d'entrée (index.php) entrouré de modules mais des scripts pour chaque type de page affichée. Avec plugins et modules je sens que l'on va induire une confusion. Mais pour trancher il me faudrait savoir comment tu compte integrer tes "modules" avec les scripts actuels ?

En tout cas je pense que la place des codes de control reste /codes. Je vais proposer les entrées d'une classe modèle "codeyacs" et le traitement associé à faire dans shared/codes.php. Si quelqu'un a le temps avant qu'il ne se gêne pas pour entamer le boulot.