Consultez la FAQ sur le ZF avant de poster une question
Vous n'êtes pas identifié.
Je suis en train de dev une petite classe toute simple, qui permettra de simplifier la gestion des fichiers de config, les connexions database, locales, translate...
L'objectif ? Plutôt, la problématique qui m'a poussé à écrire une classe de ce genre :
En règle générale, l'instancation de Zend_Config, Zend_Db, etc... se fait dans le boot.
Si l'on as un seul fichier de config et une seule connexion db, et qu'on doit les utiliser dans toutes nos pages, le problème ne se pose pas.
En revanche, il se peut que l'on ai plusieurs fichiers de config, plusieurs connexion database, mais que l'on ai pas besoin de tous ces derniers dans toutes nos pages. Dans ce cas là, les instanciations sont une perte de performance.
Mon idée (assez simpliste), c'est de pré-configurer mes objets dans le boot, puis de les utiliser.
Un exemple pour mieux comprendre :
// Ici on pré-configure, donc aucune instanciation Zendex_Setup::addConfig('default', API_ROOT.'/conf/config.xml', 'prod'); Zendex_Setup::addConfig('custom', API_ROOT.'/conf/configCustom.xml', 'prod'); // Ensuite dans notre controller ou autre, si on a besoin d'un fichier de config spécifique : Zendex_Setup::getConfig('default');
Zendex_Setup::getConfig() est assez simple à comprendre :
- si l'objet demandé n'a jamais été instancié, on l'instancie et l'enregistre dans le registry, puis on renvoi l'objet.
- si l'objet existe, on le renvoi simplement
Cela permet donc d'instancier uniquement ce dont on a vraiment besoin.
Qu'en pensez vous ?
Hors ligne
Ben l'idée est pas mal. J'avais commencé à faire une base dnas le genre mais j'ai abandonné lorsque je me suis rendu compte qu'en fait les codes, bien que ressemblant dans l'ensemble sont quand même souvent différent.
En revanche, il se peut que l'on ai plusieurs fichiers de config, plusieurs connexion database, mais que l'on ai pas besoin de tous ces derniers dans toutes nos pages. Dans ce cas là, les instanciations sont une perte de performance.
Ce genre de problème sont à la charge du developpeur. A lui d'assurer!
Hors ligne
Mr.MoOx a écrit:
Ce genre de problème sont à la charge du developpeur. A lui d'assurer!
Qu'entends-tu par là ? Justement, l'objectif du setup est de permettre au developpeur d'assurer, sans se casser la tête et tout en ayant toutes les configurations dans le boot..
Hors ligne
Mr.MoOx a écrit:
Un bon developpeur doit se casser la tête
Je dirais plutôt, qu'un bon développeur doit mettre des outils et des méthodes en place pour ne pas se casser la tête
Hors ligne
Mr.MoOx a écrit:
Il doit donc bien se casser la tete a un moment ou a un autre pour faire ces outils
Exact !
Hors ligne
je vous renvois sur mon blog ou j'ai abordé ce sujet
http://sekaijin.ovh.org/?p=7
A+JYT
Hors ligne