Consultez la FAQ sur le ZF avant de poster une question
Vous n'êtes pas identifié.
Pages: 1
Bonjour à tous !
J'ai commencé à implémenter divers éléments de base dans mon application Zend et j'aimerais un avis sur le caractère judicieux de cette implémentation.
Pour l'heure, je me suis concentré sur l'initialisation au sein du bootstrap via des plugins de ressources.
Conjointement à l'édition de clés resources.X dans un fichier de configuration INI (/configs/application.ini) j'ai créé un dossier /library/My/Application/Resource avec, respectivement, :
* SESSION
resources.session.* : données de configuration de l'adapter.
My_Application_Resource_Session, surchargeant la méthode init() de Zend_Application_Resource_Session pour placer la session dans Zend_Registry.
* DB
resources.db.* : données de configuration de l'adapter
* Views
resources.view.* : données de configuration de l'adapter, ajoutant des paths.
* LOCALE
resources.locale.* : données de configuration, dont la locale par défaut et ajoutant une clé (.activated = bool) pour l'activation ou non du multilinguisme + une clé tableau pour les locales autorisées par l'application (.allowed[] = en, fr, ..)
My_Application_Resource_Locale, surchargeant la méthode getLocale() de Zend_Application_Resource_Locale pour ajouter dans Registry le caractère multilingue de l'application + définir la locale en fonction (prioritairement) d'une éventuelle variable en session ou de la langue par défaut choisi par l'utilisateur dans son compte ou de la locale de l'utilisateur (browser) ou celle par défaut (config)
* TRANSLATE
resources.translate.* : données de configuration
My_Application_Resource_Translate, surchargeant la méthode getTranslate() de Zend_Application_Resource_Translate afin de pouvoir ajouter simultanément plusieurs fichiers de langue à un adapter sous forme de tableau au lieu d'un seul chemin (ce qui a neccessité une surcharge de Zend_Translate_Adapter et de Zend_Translate_Adapter_Tmx pour hériter de l'Adapter (il faudrait étendre la modification à chaque adapter pour être cohérent toutefois en vue d'éventuelles sources de données futures)
* Router
resources.router = ""; // juste pour que la ressource se charge automatiquement
My_Application_Resource_Router, surchargeant la méthode getRouter() de Zend_Application_Resource_Router afin d'ajouter de nouvelles routes (en particulier une route multilingue dans le cas où l'application est multilingue (statut récupéré de la ressource de Zend_Locale via Zend_Registry)
* CONFIG
Ici simplement une méthode _init() dans le bootstrap pour stocker la config en session ( Zend_Registry::set('config', new Zend_Config($this->getOptions())); )
Aux yeux de votre expérience l'approche vous semble-t-elle bonne ? Et plus précisément :
1/ Certains traitements particuliers auraient-ils dû être faits ailleurs que dans un plugin de ressource ? Si oui à quel niveau éventuellement ?
2/ La surcharge de l'adapter abstract de Zend_Translate + des adapters parait être une bonne solution ? Ou est-il plus judicieux de faire X addTranslation pour ajouter plusieurs fichiers ? (ma problématique réelle étant qu'un même nom de fichier se trouve dans 3 chemins différents et je ne voulais pas faire add("/languages/file.tmx") + add("/../languages/file.tmx) + add("/../../languages/file.tmx) pour chaque fichier..) mais tous passer en même temps dans un tableau (dans le constructeur et dans une méthode AddMultipleTranslation qui appelle addTranslation() pour les 3 chemins )
Merci
Edit: Ajout de 'Router' et 'View'
Dernière modification par Eureka (13-08-2009 18:16:09)
Hors ligne
3/ Dans le cas où un traitement vient après le code actuellement spécifié dans les plugins de resource, serait-il plus judicieux de ne pas étendre les classes Zend_Application_Resource_* pour ajouter le code après les traitements existants et plutôt ajouter dans le bootstrap des fonctions _init qui récupèrait la resource et ajouterait alors le traitement ?
Au lieu de :
class My_Application_Resource_Session extends Zend_Application_Resource_Session { public function init() { $options = array_change_key_case($this->getOptions(), CASE_LOWER); if (isset($options['savehandler'])) { unset($options['savehandler']); } if (count($options) > 0) { Zend_Session::setOptions($options); } if ($this->_saveHandler !== null) { Zend_Session::setSaveHandler($this->_saveHandler); } // ajout de ma ligne Zend_Registry::set('session', new Zend_Session_Namespace('xxxx')); } }
Faire :
class My_Bootstrap extends Zend_Application_Bootstrap_Bootstrap { protected function _initSession2() { // appel la resource Zend_Application_Resource_Session (et non la surcharge) $this->bootstrap('session'); $this->getResource('session'): // ajout de ma ligne Zend_Registry::set('session', new Zend_Session_Namespace('xxxx')); } }
J'ai étendues les plugins de resource de Zend pour ajouter des routes, modifier la locale en fonction de la session ou de la langue pas défaut de l'utilisateur en base, ajouter des fichiers de traduction, ...
Ayant lu à diverses reprises que le bootstrap devait être le plus vide possible, j'ai tendance à vouloir essayer de caser le maximum de code au sein des plugins resources...
L'exemple ci-dessus n'est peut être pas le plus judicieux car très "simple" en soit. Dans le cas de la locale, j'ai surcharger la méthode getLocale() pour mettre dans Zend_Registry que l'application était multilingue ou non et que la locale se base sur la session, ou la préférence utilisateur..
Dernière modification par Eureka (18-08-2009 15:48:55)
Hors ligne
Pages: 1