Re: Première version

Olivier Pascal wrote:
> Si je déclare selon ton modèle que "Je suis le module Identification et 
> j'implémente un gestionnaire qui doit être absolument exécuté avant le module 
> X" et que je supprime le module X ? quand va se dérouler l'identification ?

Sans problème. Si le module X n'existe pas la condition est 
automatiquement validée.
En interne je crée un module virtuel X qui ne contient rien, le temps du 
tri. Après le tri je supprime tous les virtuels pour ne pas trop faire 
de bordel.

> Si c'est bien ce que je pense, ça me parrait gérable avec 2 ou 3 modules mais 
> dès que tout le monde se mettra à en créer ...

L'option permet justement de faire du virtuel. On peut se permettre de 
créer un faux module "identification", à chacun de se placer par rapport 
à la phase d'authentification (avant/après). Mais chacun peut 
positionner ses propres étapes en plus (virtuelles ou pas). On reste 
décentralisés.

> Ce qu'il faudrait peut-être c'est rammener les dépendances aux modules 
> initiaux comme "core" ou "UriParser". Le core pourrait contenir des 
> évènnements standards de référence dans le core, "initialisation", 
> "transformation", et "sortie" par exemple. Le module "Identification" 
> pourrait définir un évènnement de haute priorité placé juste après 
> "initialisation" pour se lancer en premier. 

C'est un peu ça, sauf que n'importe qui peut créer une référence qui 
servira aux autres modules. Il sera en effet indispensable de définir 
nous même quelques noms de base pour symboliser les étapes courantes. 
Ceci dit logiquement ces étapes de bases devraient se retrouver être 
justement les modules qu'on implémentera en premier (identification, 
interprétation, transformation ...)

> Mais il y a toujours un 
> problème : si je veux définir un évènnement pour lancer un gestionnaire de 
> module de Log juste avant "idenfication" ?

dans log tu mettra : <just-before>identification</just-before>


> Moi je pensais laisser les modules se débrouiller avec leurs fichiers de conf 
> (un ou plusieurs) vu que IniHandler les cache automatiquement dès de leurs 
> première ouverture.
> Les fichiers de conf INI sont dans tous les cas à utiliser avec parcimonie ! 
> (voir fs.php)

Oui, mais qui dit fichier de cache dit au moins 1 accès en lecture et 
deux accès stat(). Avec 20 modules ça devient non négligeable.
Là la seule différence c'est qu'on charge tout d'un coup pour éviter de 
le faire ensuite, mais sinon ça ne change pas grand chose.

> Exact. Toujours pour rabacher les 2 ms qui ne me paraissent pas exégérés 
> permettent de gagner en souplesse et en facilité d'utilisation alors que ta 
> méthode impose de faire des copies de fichiers, de gérer ce cache, et ne 
> permet pas de gérer les sous-dossiers.

Imagines mes 20 modules. Dans l'idéal la classe du premier module aura 
besoin d'une lecture de rep, la classe du second aura besoin de 2, etc. 
On va avoir au minimum 1+2+3+4+5....+20 = 100 lectures de rep juste pour 
charger 1 classe par modules. Si on en charge plusieurs ou qu'on 
autorise les sous-rep dans les modules on va vite exploser.
Si on rajoute la même chose pour les fichiers de conf, pour les data 
.... on va finir par faire plus de 300 accès fichiers juste pour 
afficher un article. Là ce n'est même plus de la perf, c'est carrément 
pour ne pas diminuer la durée de vie du disque ;)

Ceci dit la méthode prévue peut tout à fait gérer les sous dossiers, il 
suffit de faire explorer un peu plus loin à la génération. La seule 
différence réelle c'est que l'exploration n'aura lieu qu'une fois à la 
génération et plus pendant les exécutions.


> A ce momment là les notions de valeurs booléennes, d'options, indexs, etc. ne 
> servent plus à grand chose, autant utiliser en tout et pour tout 
> parse_ini_file() !

Pourquoi ? le contenu est le même. Les options, les valeurs booléennes, 
les listes et le reste servent toujours. La seule différence est de 
savoir si on interprête une fois à la génération ou à chaque exécutions.
Quand à parse_ini_file() elle ne sait même pas gérer les listes. Ça 
m'amuse d'ailleurs de voir que cette fonction ne sait même pas 
interprêter le contenu du php.ini en entier (puisque extension= .. est 
une liste éclatée)
D'autant qu'on en aura besoin aussi pour les fonctions d'admin, qui 
nécessiteront les écritures intelligentes.

Rassures toi je suis loin de vouloir jeter ta classe à la poubelle, au 
contraire.

--
Eric