dimanche 19 avril 2009
Config avec Zend ou Pear
Dans la rubrique PHP / PEAR
Zend_Config et Pear::config sont conçus pour simplifier l'accès et l'utilisation des données de configuration dans les applications.
Les données de configuration peuvent venir de sources variées supportant une organisation hiérarchique des données.
Actuellement Zend_Config fournit des adaptateurs pour les données de configuration qui sont stockées dans des fichier textes avec Zend_Config_Ini et Zend_Config_Xml.
De son coté Pear::config propose Apache, GenericConf, IniCommented, IniFile, PHPArray, PHPConstants, XML.
Je ne suis pas encore à l'aise ni avec l'un, ni avec l'autre.
Ce qu'il me faut c'est :
- une possibilité de gérer plusieurs fichiers qui regroupent "sémantiquement" les valeurs de configuration.
- Ces fichiers doivent être administrables avec auteur et versionning des modifications.
- Il faut une gestion de staging.
- Il faut un éditeur de config auto généré.
- un cache transparent qui évite un reparsing des fichiers.
- Une possibilité d'overrider une valeur au niveau applicatif.
edit : Oops c'est article a été publié inachevé.
Le fond du problème c'est de se dire qu'une config c'est avant tout une liste de valeurs variable/paramétrable dont la valeur n'est pas assignée par le développeur, mais par un utilisateur.
- un administrateur technique (même si c'est la même personne. Ce n'est pas la même casquette. Le développeur c'est celui qui crée le code, l'administrateur technique c'est celui qui dit comment il va fonctionner.)
- un administrateur non technique qui n'a pas à bidouiller dans un fichier de config. (même s'il prétend en être capable)
Pour ce dont j'ai besoin
- Il faut une gestion de staging. <- existe dans Zend_config (cfr commentaire fragile)
- un cache transparent qui évite un reparsing des fichiers. <- possible avec PEAR et ZF
- Une possibilité d'overrider une valeur au niveau applicatif. <- possible mais il faut le prévoir soigneusement dans le code
On avait implémenté plusieurs des autres points dans Claroline mais ce dernier n'utilise ni PEAR::Config, ni Zend_Config
L'idée est d'avoir une config de config.
Avoir une liste des valeurs de config avec leur définition, contexte, type, ...
Avoir un outil d'édition des fichiers de config qui se base sur ces listes pour
- afficher le formulaire d'édition de des fichiers de config
- versionner les modification de config, ou tout du moins "logguer"
Pear::Config
Pear::Config aide à manipuler votre configuration qu'elle soie stockée dans des fichiers XML, des tableaux PHP ou tout autre genre de source de données. Il comporte les fonctionnalités suivantes :
- Analyser les différents formats de configuration.
- Manipuler les sections, directives, commentaires, blancs de la manière que vous voulez.
- Réécrire de nouveau les données dans votre format préféré.
L'objet de Config agit en tant que conteneur pour d'autres objets de Config_Container. Il ne fait pas beaucoup mais rend la tenue des opérations de E/S plus faciles. Il contient l'objet racine de Config_Container qui contient alternativement un objet enfant de Config_Container. Les objets Config_Container stockent des références à leur parent et ont un tableau d'enfants. Cette structure permet alors d'accéder à différent les conteneurs et leur contenu.
Un objet de Config_Container peut être de différents types :
- Section: une section contient d'autres objets Config_Container.
- Directive: une directive ne contient aucun autre objet mais a un contenu et un nom. Voyez-les comme des paires de clef-valeur.
- Commentaire: comme les directives, les commentaires ont un contenu mais elles n'ont pas de nom. Elles sont rendues d'une manière spéciale selon le type de configuration que vous choisissez.
- Blanc: elles n'ont ni contenu ni nom mais sont utilisées pour indiquer les interlignes si votre _renderer_ les emploie.
En utilisant le paquet Config, la majeure partie du travail est effectuée avec les objets Config_Container .
Zend_Config
On voit donc un petit avantage à PEAR_Config c'est qu'il propose aussi l'écriture.
Pour creuser Zend_Config : Différentes approches et sa partie 2
Claroline
Les valeurs de configuration actives seront stockées dans des fichiers de config contenant de simples array php.
[php] <?php /* campus_name : Name of your campus */ $claro_config['platform_name'] = 'My campus'; /* platform_language : Select the default language of the platform */ $claro_config['platform_language'] = 'english'; /* claro_stylesheet : Set the stylesheet layout */ $claro_config['platform_stylesheet'] = 'default.css'; /* administrator_name : Complete name */ $claro_config['administrator_name'] = 'John Doe'; /* administrator_email : This email is the main contact address on the platform */ $claro_config['administrator_email'] = 'John@doe.net'; /* administrator_phone : Phone */ $claro_config['administrator_phone'] = ""; /* institution_name : Name displayed in the top banner */ $claro_config['institution_name'] = 'My institute'; ?>
Mais ce qui est particulier est en amont.
Dans claroline, on ne distribue plus jamais les fichiers de config. mais des fichiers de définition.
L'outil d'édition de config, (et d'install et d'upgrade) lit le fichier de définition et il lit les valeurs actives si elles existent dans les fichiers de config.
Ensuite il génère le forumlaire, on peut editer comme on veut puis dire, "appliquer", "restaurer les valeur par défaut", "abandonner"
Si on utilise "appliquer" il regénère tous les fichiers de conf concernés
L'avantage c'est qu'à l'upgrade on écrase les fichiers de définition pas les valeurs actives.
voici a quoi ressemble la définition d'une valeur de config.
[php]
<?php
$toolConfProperties['CONFVAL_LOG_CALENDAR_INSERT'] =
array ('label' => 'Logguer les ajouts d\'agenda'
,'default' => 'TRUE'
,'type' => 'boolean'
,'display' => TRUE
,'readonly' => FALSE
,'container' => 'CONST'
,'acceptedval' => array ('TRUE'=>'enabled'
,'FALSE'=>'dislabed'
)
);
?>
- CONFVAL_LOG_CALENDAR_INSERT <- nom du conteneur
- container => 'CONST' <- type du conteneur
donc ici il génère un define('CONFVAL_LOG_CALENDAR_INSERT', ...)
- default => 'TRUE' <- valeur proposée par défaut
- type => 'boolean' <- permet de définir le contrôle sur valeur recue et l'aspect du formulaire on peut mettre boolean, integer, string, enum, enum+, ereg, si boolean,'acceptedval' => array ('TRUE'=>'enabled','FALSE'=>'dislabed') perment de mettre le nom à coté des radios
- display = TRUE;
- readonly = FALSE;
Ces deux là permettent d'afficher ou non une valeur dans l'éditeur et de la rendre editable ou non
un autre exemple
[php]
<?php
$toolConfProperties['DEFAULT_SUFFIX_MAIL']['default'] = '@fake.zz';
$toolConfProperties['DEFAULT_SUFFIX_MAIL']['type' ] = 'regexp';
$toolConfProperties['DEFAULT_SUFFIX_MAIL']['acceptedval'] = '@(([0-9]{1,3}\.){3}[0-9]{1,3}|([0-9a-z][0-9a-z-]*[0-9a-z]\.)+[a-z]{2,4})$';
?>
Maintenant avec Zend ou Pear on pourrait transformer une partie de l'éditeur auto généré pour utiliser Zend_Form ou PEAR::Quickform2
Conclusion
Rien Ne me convient, je suis un difficile capricieux.
Il va falloir que je planifie tout ceci.
4
-![[T]](http://static.technorati.com/pix/icn-talkbubble.gif)
Les Package PEAR pour l'
Étant donné que ces questions sont de plus en plus récurrentes sur sa boîte mail ou sur les mailing-lists de PEAR,
il a décidé d'écrire cette série de petits tutoriaux :
Je viens d'apprendre avec effarement le décès de 
Arnaud demande ce 
