Re: Première version

Le Mardi 30 Mars 2004 20:08, Eric Daspet a écrit :
> Olivier Pascal wrote:
> > Je n'ai pas trop bien compris le but de ta procédure en fait.
>
> Bon, alors je reprend en plus clair.

Merci !

> Pour ces deux problèmes il y a deux manières de gérer la choses :

> - en automatique, en laissant chaque module faire ses propres
> déclarations du type "Je suis le module M, je suis prioritaire par
> rapport aux modules A et B, j'implémente les gestionnaires X et Y, X
> doit absolument être exécuté avant Z, Y doit absolument être exécuté
> avant W"

Ce qui me trouble ici c'est que les déclarations sont (forcemment) relatives 
aux autres modules et à priori il faut savoir qu'ils existent. Donc les 
modules sont forcemment dépendants.

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 ?

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 ...


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. 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" ?

Enfin c'est peut-être ce à quoi tu pensais et moi qui viens juste de 
comprendre ;-)

> Mes problèmes de performances sont les suivants :
> 3/ explorer tous les répertoires pour lister les fichiers de conf, les
> ouvrir, les interprêter à base de regexp et construire des tableaux.
> Même avec un cache ça nécessite au minimum X listages de dossier, X
> ouverture de fichiers et X stat(), où X est le nombre de modules.

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)

> 4/ lors de l'autoload je comptais lister tous les rep des modules en
> include_path, ou faire explorer ces répertoires à la fonction d'autoload
> (peu importe, ça revient en gros au même). Mais avec le nombre de
> chargements à chaque exécution le coût devient réel. Il faudrait pouvoir
> savoir exactement où est le bon fichier à inclure (que ce soit en
> construisant un index ou en recopiant les fichiers dans un rep commun)

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.

> Pour la configuration ça nous permet même de ne charger lors des
> exécutions de lecture une classe qui ne fait que lire un tableau
> associatif : aucun appel aux fichiers, aucune exploration, aucune

> interpétation. On réserve la classe de lecture/écriture aux fonctions
> d'admin (dont le tri des modules)

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() !

-- 
Olivier Pascal