Consultez la FAQ sur le ZF avant de poster une question
Vous n'êtes pas identifié.
Pages: 1 2
Bonsoir,
Alors me voilà lancé dans le framework zend, avec pour objectif de créer un site correcte du premier coups.
J'ai donc besoin de conseil:
-Ou dois-je faire la connection à ma base de donnée?
Dois-je créer une classe dans les modèle et l'appeller dans le boostrap ?
Merci de votre aide
Hors ligne
Bonjour,
y'a déjà des classes toutes faites pour ça, jette un oeuil sur http://www.z-f.fr/page/comment_debuter, tu trouveras toute une liste de tutos où tu trouveras ta réponse
Hors ligne
Perso pour un test où la base de données est obligatoire, je fais la connexion dans le bootstrap et la teste pour ne pas avoir à aller plus loin si ça plante.
Hors ligne
Merci pour vos réponses,
J'ai suivi un des tutos qui fais la connection dans l'index (sans bootstrap)
Est-ce vraiment important le bootstrap et peut on se contenter d'un simple index ?
Merci
Hors ligne
dans le contexte MVC le bootstrap c'est l'index ( il est possible de le nommer autrement il suffis de modifier le htaccess ou la conf apache en conséquence )
Dernière modification par lethak (18-09-2008 21:01:48)
Hors ligne
Hello,
En théorie dans ton index.php, tu as seulement qqch du genre :
require_once 'monbootstrap.php'; monbootstrap::run();
Dans le cas où ton serveur web plante (n'interprète plus le php par exemple), le visiteur ne verra que ce qu'il y a ci-dessus.
Ton bootstrap lui est dans un dossier non accessible via Apache.
Si tu suis cette page, seul public est accessible via Apache.
A+
Dernière modification par mikaelkael (18-09-2008 22:10:09)
Hors ligne
Je me permets de récapituler et de prolonger les conseils donnés à squall6969 :
-En dev on a intérêt à appeler pour les tests unitaires des accés à la bd à passer par index.php.
-Mais en vue de la prod on a intérêt à avoir une classe Bootstrat dans lequel chaque ressource à configurer le soit à partir d’une méthode du type setupDb , celle-ci faisant appel à son tour au fichier de config pour ce qui est variable dans la config.
Un ex incomplet car en chantier (donc il peut y avoir des erreurs) de classe Bootstrap :
<?php require_once 'Zend\Loader.php'; class Bootstrap { public static $frontController = null; public static $root = ''; public static $registry = null; public static function run() { self::setupEnvironment(); Zend_Loader::registerAutoload(); self::setupRegistry(); self::setupConfig(); self::setupResponse(); self::setupFrontController(); self::setupDataBase(); self::setupView(); sef::setupLayout(); self::setupAcl(); self::setupLog(); self::setupSession(); self::setupCache(); $response = self::$frontController->dispatch(); self::sendResponse($response); } public static function setupEnvironment() { error_reporting(E_ALL|E_STRICT); ini_set('display_errors', true); date_default_timezone_set('Europe/Paris'); self::$root = dirname(dirname(__FILE__)); self::_disableMagicQuotes(); } … }
un ex également d’index.php :
<?php define('ROOT_DIR', dirname(dirname(__FILE__))); set_include_path(get_include_path() . PATH_SEPARATOR . ROOT_DIR . '/' . PATH_SEPARATOR . ROOT_DIR . '/libraries/' . PATH_SEPARATOR . ROOT_DIR . '/application/default/models/dbAccess' ); require_once 'application/Bootstrap.php'; Bootstrap::run();
Avec Class Bootstrat et zend framework on trouve des ex sur google mais il y a surtout la 3eme partie du tutoriel de Padraic Brady dont je suis parti (en cache de google son site astrum futura ayant disparu) :
http://209.85.135.104/search?q=cache:ig … &gl=fr
et un autre dans le même genre : http://raiyaraj.wordpress.com/2008/08/0 … bootstrap/
Les arguments en faveur de l’usage d’une telle classe sont à mon avis :
-plus de lisibilité du fait de la modularisation du code par rapport à un index.php classique: la configuration est résumée par le contenu de la méthode run figurant ci-dessous avec le début d’une classe qui est encore en chantier.
-plus d’évolutivité donc.
Reste des doutes sur ce qu’on doit mettre dans ce bootstrap : Faut il y mettre la configuration du langage php lui-même , la configuration de l’appli ou même le déclenchement de la génération de certains éléments fixes comme des menus à mettre en cache. A mon avis pour ce dernier point une classe nommée par ex StaticRessourcesController dans un module Admin avec des méthodes setup conviendrait mieux. S’il y a d’autres avis sur cette question cela m’intérèsse.
En espérant que cela puisse intéresser voire aider.
Dernière modification par Mr.MoOx (19-09-2008 12:27:11)
Hors ligne
Hello,
Juste pour dire que l'article Padraic Brady est de retour sur le net. Le raz de marée sur son site lors de la sortie de cet article avait entraîné la fermeture du compte par son hébergeur .
Lien : http://www.mt-soft.com.ar/2008/04/28/an … -tutorial/
A+
Dernière modification par mikaelkael (19-09-2008 11:37:22)
Hors ligne
mikaelkael a écrit:
Hello,
En théorie dans ton index.php, tu as seulement qqch du genre :Code:
require_once 'monbootstrap.php'; monbootstrap::run();Dans le cas où ton serveur web plante (n'interprète plus le php par exemple), le visiteur ne verra que ce qu'il y a ci-dessus.
Ton bootstrap lui est dans un dossier non accessible via Apache.
Si tu suis cette page, seul public est accessible via Apache.
A+
Très mauvais sur des sites a forte charge je pense
un seul include ne fait pas trop de dif, mais quand on en a un peux partout c'est une goutte de plus vers le plantage serveur, Particulièrement en cas de pic de fréquentation.
Dernière modification par lethak (19-09-2008 12:54:25)
Hors ligne
Hello,
Très mauvais sur des sites a forte charge je pense
Je parle avant tout de sécurité . Je suis d'accord que c'est dommage d'avoir un si petit fichier.
A+
Hors ligne
<quote>
lethak a dit :
Très mauvais sur des sites a forte charge je pense
</quote>
je n'ai pas de stats sur les perfs mais il faut voir aussi qu’on est pas forcément perdant car on peut améliorer le Bootstrap en « allégeant » sa méthode run cad en enlevant un certain nbre de setup qui ne sont pas tjs utiles .Par ex qd on a pas besoin de générer une page parce qu'elle est en cache le fait d’avoir fait la connexion dans index.php correspond à posteriori à du gaspillage . Si on en avait de créer la page et donc d’aller chercher les données en bd il aurait suffit de faire monBootstrap :: setupDb. Bien sûr il n’y a pas que la bd qui puisse être concerné, il peut aussi y avoir dans le même cas le cache, la log etc..
Et puis ne peut-on pas gagner encore en perf en mettant l’objet singleton Bootstrap en cache de type apc je crois.
Autrement merci à mikaelkael pour le lien concernant le tutoriel très intéréssant de padraic brady (c’est qd mm
plus agréable comme ça qu’en cache google) , et aussi pour sa remarque concernant la possibilité de cacher du code grace à une classe Bootstrap (je n'y avais pas pensé).
Hors ligne
mikaelkael a écrit:
Hello,
Très mauvais sur des sites a forte charge je pense
Je parle avant tout de sécurité
. Je suis d'accord que c'est dommage d'avoir un si petit fichier.
A+
Alors comment faire?
Un lien symbolique?
Hors ligne
C'est vraiment pinailler.
Si votre service n'est pas capable d'interpréter un fichier de 2 lignes, changer de machine (et d'administrateur !)
On est en 2008...
Hors ligne
Je suis aussi un peu d'accord pour dire qu'un bootstrap peut rester dans un et un seul fichier.
Un require de moins, et quelques appels statics de moins, c'est toujours ca de gagner.
Sauf sur les énormes projets, je vois pas l'interêt...
^^
Hors ligne
Julien a écrit:
Je suis aussi un peu d'accord pour dire qu'un bootstrap peut rester dans un et un seul fichier.
Un require de moins, et quelques appels statics de moins, c'est toujours ca de gagner.
Sauf sur les énormes projets, je vois pas l'interêt...
^^
Je suis de cet avis, enfin bon on peut toujours trouver des arguments, mais là c'est inutile de compliquer et d'alourdir pour un gain hypothétique.
Hors ligne
nORKy a écrit:
C'est vraiment pinailler.
Si votre service n'est pas capable d'interpréter un fichier de 2 lignes, changer de machine (et d'administrateur !)
On est en 2008...
en fait il y a moultes et moultes machines ( je ne suis pas archi réseau ) mais TOUT doit etre optimisé pour les pic de charge ( + de 200 000 visites )
gchau a écrit:
<quote>
lethak a dit :
Très mauvais sur des sites a forte charge je pense
</quote>
je n'ai pas de stats sur les perfs mais il faut voir aussi qu’on est pas forcément perdant car on peut améliorer le Bootstrap en « allégeant » sa méthode run cad en enlevant un certain nbre de setup qui ne sont pas tjs utiles .Par ex qd on a pas besoin de générer une page parce qu'elle est en cache le fait d’avoir fait la connexion dans index.php correspond à posteriori à du gaspillage . Si on en avait de créer la page et donc d’aller chercher les données en bd il aurait suffit de faire monBootstrap :: setupDb. Bien sûr il n’y a pas que la bd qui puisse être concerné, il peut aussi y avoir dans le même cas le cache, la log etc..
Et puis ne peut-on pas gagner encore en perf en mettant l’objet singleton Bootstrap en cache de type apc je crois.
Autrement merci à mikaelkael pour le lien concernant le tutoriel très intéréssant de padraic brady (c’est qd mm
plus agréable comme ça qu’en cache google) , et aussi pour sa remarque concernant la possibilité de cacher du code grace à une classe Bootstrap (je n'y avais pas pensé).
Zend_DB ne se connecte réellement que lors de la première requête SQL
Dernière modification par lethak (20-09-2008 09:34:01)
Hors ligne
Hello,
Le ZF Official Quickstart adopte le fonctionnement que je décris .
Si vous cherchez la performance, c'est que vous n'utilisez pas un fichier de config (Zend_Config_Xml ou Zend_Confgi_Ini), vous pouvez donc avoir dans votre bootstrap toutes les informations de connexion à votre bdd : je pense que c'est un problème de sécurité . Vous n'utilisez pas non plus les view helpers qui utilisent le plugin loader ?
A+
Dernière modification par mikaelkael (20-09-2008 12:31:57)
Hors ligne
pour ma part j'ai dérivé la classe Zend_Controler_Front j'ai surchargé la méthode run
c'est dans celle-ci que je défini l'objet de connexion à la base.
pour qu'il soit toujours disponible.
Par contre je n'ouvre pas la connexion. je ne le fais qu'à la première requête. (en fait ZF fait ça tout seul)
il est donc nécessaire de bien traiter les exceptions pour éviter que le client se retrouve avec un page blanche.
A+JYT
Hors ligne
Moi perso j'ai un classe maison Bootstrap et j'ai ma connexion dans une méthode static chargé à partir d'une Zend_Config en paramètre...
(D'ailleurs dedans cette classe, j'ai quasiment que des initialisations en méthode static, je sais pas si c'est mieux ou non)
Je me suis inspiré du travail de sekaijin (d'ailleurs merci )
Hors ligne
En réponse à Julien et Jean-Marc je dirai que le gain à attendre d’une séparation du bootstrap en 2 fichiers( index.php et classe Bootstrap ) n’est bien sûr pas en performance au sens utilisation du logiciel mais de son dvpt et de sa maintenance.
Autrement dit ce que vise cette séparation du bootstrap en deux c’est à limiter les adaptations du bootstrap à des modifications d’un petit fichier index.php et également à rendre la classe Bootstrap non seulement stable pour une même appli mais réutilisable d’une appli à l’autre (quitte à l’étendre).
Actuellement ce qu’on peut faire varier dans l’index.php, que j’ai proposé, c’est l’include_path mais on peut aller plus loin pour rendre plus stable la classe Bootstrap.
Avant de parler de ces améliorations je voudrais préciser ce que j’entends par bootstrap ,pris au sens générique (cad avec 1 ou 2 fichiers): A mon avis le bootstrap est une « couche » qui met à la disposition d’un traitement d’une appli toutes sorte de ressources qui sont principalement ZF mais qui sont aussi php (la date, les car spéciaux, la mémoire etc..) et d’autres encore (par ex si on utilise une base directement sans passer par zend_db ).
Avoir une classe Bootstrap (de base) très stable cela signifie pour moi, qu’elle doit beaucoup s’appuyer sur des fichiers de config ( en particulier pour tout ce qui est path) et aussi qu’au lieu d’avoir une méthode run principale figée (toutes les applis n’ont pas besoins des mêmes ressources et tous les traitements d’une même appli n’ont pas besoin des mêmes ressources : pour reprendre mon ex d'un post précédent une connection à la bd n’est pas tjs nécessaire au traitement) il faudrait mettre le contenu de cette méthode run (cad les diffts setup comme setupDb ) soit soit directement dans index.php soit dans une fonction (qui ne soit pas une méthode) appellée par lui.
Dans le prolongement de ceci je dirai à Sekajin qui a une méthode différente pour séparer en 2 le bootstrap que la stabilité de son bootstrap ne me parait pas idéale du fait qu’elle dépend de celle de la classe front controller de ZF (qui est sans doute très stable depuis un petit moment mais qui sait…) .
Concernant l’argument de limiter les include au maximum d’accord mais sérieusement est ce qu’un require_once(‘Bootstrap.php’) va changer grand-chose quand on voit toutes les classes ZF qu’on doit charger.
Enfin excusez moi si je suis parfois un peu trop compliqué et peut être borné à la fois . Je connais bcp moins bien php et ZF que la plupart d’entre vous mais sachez que je vous suis reconnaissant de tout ce que vous m’avez appris indirectement sur plein de pbmes que j’ai rencontré sur ZF. De toute façon j’ai peut-être tort de me casser la tête au sujet de ce bootstrap car il est possible qu’un jour prochain ZF nous propose sa propre classe Bootstrap comme le laisse espérer le lien cité par mikaelkael. Il va falloir que je pense à faire plus court la prochaine fois ….
Hors ligne
Hello,
Autre lien vers une proposal qui débute : Zend_Bootstrap
A+
Hors ligne
Bonsoir,
Merci mikaelkael pour ce lien mais je regrette quand même la minceur de cette proposition même si elle en est au tout début.
Matthew Weier Ophinney lui-même s’est penché sur la question cf son tutoriel sur les plugins traduit et revu par Julien dans lequel il donne une ébauche de bootstrat sous forme d’un plugin déclenché par l’évènement routestartup.
http://julien-pauli.developpez.com/tuto … _2#LII-D-1
Une implémentation bcp plus conséquente de ce plugin se trouve dans l’application pastebin associée à un tuto sur l’intégration Dojo ZF (http://weierophinney.net/matthew/upload … 0.0.tar.gz) .
Si on fait abstraction du mode d’appel c’est équivalent pour l’essentiel, non seulement fonctionnellement mais aussi au niveau du code, à une classe Bootstrap avec en plus un avantage :
En effet, à défaut d’être une implémentation officielle, on est sûrement plus dans la philosophie ZF qu’avec une classe Bootstrap du type de celle que j’avais évoquée dans un précédent post car cette fois il s’agit d’une extension de la classe plugin qui fait partie intégrante du cadre MVC étendu de ZF. A noter que la méthode de sekajin permet aussi de rester dans le cadre ZF sans ajout d’un nouveau type de classe.
Mais cette « économie conceptuelle » se fait-elle au détriment d’avantages qu’aurait une nouvelle classe Bootstrap et que n’aurait pas ce plugin :
-Avec une classe Bootstrap il est facile d’appeler depuis un objet modèle une méthode setupDb de cette classe pour initialiser une connexion si elle n’existe pas (rappel : ceci pour alléger la méthode run du bootstrap cf
épisodes précédents) mais faire la même chose lorsque cette méthode se trouve dans un plugin si c’est possible c’est certainement plus compliqué ( en passant par le broker j’imagine…).
-Les performances d’une classe Bootstrap sont certainement plus facile à optimiser (cache.. ) que celle d’un
plugin.
Voilà où j’en suis de mes réflexions et de mes questions sur le sujet, en espérant avoir intéressé quelqu'un.
A+
Hors ligne
Pour information ZS 6.1.0 propose maintenant initializer.php et bootstrap.php par défaut.
public/index.php
<?php /** * My new Zend Framework Project * * @author * @version */ require '../application/bootstrap.php';
application/bootstrap.php
<?php /** * My new Zend Framework project * * @author * @version */ set_include_path('.' . PATH_SEPARATOR . '../library' . PATH_SEPARATOR . '../application/default/models/' . PATH_SEPARATOR . get_include_path()); require_once 'Initializer.php'; require_once "Zend/Loader.php"; // Set up autoload. Zend_Loader::registerAutoload(); // Prepare the front controller. $frontController = Zend_Controller_Front::getInstance(); // Change to 'production' parameter under production environemtn $frontController->registerPlugin(new Initializer('development')); // Dispatch the request using the front controller. $frontController->dispatch(); ?>
application/initializer.php
<?php /** * My new Zend Framework project * * @author * @version */ require_once 'Zend/Controller/Plugin/Abstract.php'; require_once 'Zend/Controller/Front.php'; require_once 'Zend/Controller/Request/Abstract.php'; require_once 'Zend/Controller/Action/HelperBroker.php'; /** * * Initializes configuration depndeing on the type of environment * (test, development, production, etc.) * * This can be used to configure environment variables, databases, * layouts, routers, helpers and more * */ class Initializer extends Zend_Controller_Plugin_Abstract { /** * @var Zend_Config */ protected static $_config; /** * @var string Current environment */ protected $_env; /** * @var Zend_Controller_Front */ protected $_front; /** * @var string Path to application root */ protected $_root; /** * Constructor * * Initialize environment, root path, and configuration. * * @param string $env * @param string|null $root * @return void */ public function __construct($env, $root = null) { $this->_setEnv($env); if (null === $root) { $root = realpath(dirname(__FILE__) . '/../'); } $this->_root = $root; $this->initPhpConfig(); $this->_front = Zend_Controller_Front::getInstance(); // set the test environment parameters if ($env == 'test') { // Enable all errors so we'll know when something goes wrong. error_reporting(E_ALL | E_STRICT); ini_set('display_startup_errors', 1); ini_set('display_errors', 1); $this->_front->throwExceptions(true); } } /** * Initialize environment * * @param string $env * @return void */ protected function _setEnv($env) { $this->_env = $env; } /** * Initialize Data bases * * @return void */ public function initPhpConfig() { } /** * Route startup * * @return void */ public function routeStartup(Zend_Controller_Request_Abstract $request) { $this->initDb(); $this->initHelpers(); $this->initView(); $this->initPlugins(); $this->initRoutes(); $this->initControllers(); } /** * Initialize data bases * * @return void */ public function initDb() { } /** * Initialize action helpers * * @return void */ public function initHelpers() { // register the default action helpers Zend_Controller_Action_HelperBroker::addPath('../application/default/helpers', 'Zend_Controller_Action_Helper'); } /** * Initialize view * * @return void */ public function initView() { // Bootstrap layouts Zend_Layout::startMvc(array( 'layoutPath' => $this->_root . '/application/default/layouts', 'layout' => 'main' )); } /** * Initialize plugins * * @return void */ public function initPlugins() { } /** * Initialize routes * * @return void */ public function initRoutes() { } /** * Initialize Controller paths * * @return void */ public function initControllers() { $this->_front->addControllerDirectory($this->_root . '/application/default/controllers', 'default'); } } ?>
Hors ligne
Bonjour,
@ fte : Honnêtement je tombe des nues, n’utilisant pas zend studio j’ignorais totalement et je n'ai rien trouvé de tel sur zf 1.6.1 (sauf erreur de ma part) en tout cas merci du renseignement et pour les sources.
J’ose quand même espérer qu’il n’y a pas des tonnes d’autres différences entre ZS et ZF cad version payante
et version libre sinon ça va faire mal à pas mal de petits développeurs ...
Hors ligne
Hello,
Attention Zend Studio n'est pas l'environnement de dév DU Zend Framework. C'est du côté de Zend_Tool qu'il faut regarder. C'est un chantier dans le laboratory pour l'instant.
Voir http://framework.zend.com/wiki/display/ … +-+General
A+
Hors ligne
Pages: 1 2