Consultez la FAQ sur le ZF avant de poster une question
Vous n'êtes pas identifié.
Pages: 1
Bonjour à tous,
Je débute actuellement sur le framework et je suis déjà bien embêté car j'aimerai utiliser de bonnes pratiques et conventions de nommage mais je ne sais déjà même pas où placer le fichier index.php ?!
En suivant les tutoriaux proposés dans la rubrique "Comment Débuter" vous pourrez constater que chaque tutoriel utilise une architecture différente :
Initiation au MVC sur la doc du ZF (FR Zend)
application/ controllers/ IndexController.php models/ views/ scripts/ index/ index.phtml html/ .htaccess index.php
Tutoriel avancé MVC au Zend Framework 1.0.0 (FR Kitpages)
PHP-INF/ ctrl/ IndexController.php model/ views/ scripts/ index/ index.phtml .htaccess index.php
Tutoriel Rob Allen traduit en français (FR developpez)
application/ controllers/ IndexController.php models/ views/ scripts/ index/ index.phtml public/ images/ scripts/ styles/ .htaccess index.php
Quelle architecture est la bonne ? Où placer le fichier index.php (racine ou sous-dossier) ?
Merci d'avance pour votre aide
Hors ligne
Perso j'utilise actuellement celle ci
application/ .htaccess controllers/ models/ views/ layouts/ scripts/ public/ .htaccess img/ js/ css/ index.php
Mais jusqu'a assez récemment j'utilisais celle là:
application/ .htaccess controllers/ models/ views/ scripts/ public/ .htaccess img/ js/ css/ .htaccess index.php
Après je ne sais pas si y'a de solutions ultimes. Avec un coup de htaccess on peux trouver plusieurs solutions propres je pense.
Hors ligne
Mr.MoOx a écrit:
Mais jusqu'a assez récemment j'utilisais celle là:
...
Pourquoi avoir changé ?
Et est-ce que ceci a impliqué beaucoup de changements ? (modifications de liens, configuration du serveur, ...)
Hors ligne
Pourquoi avoir changé ? -> Comme ça. Non en fait je n'aimais pas avoir un fichier index.php perdu tout seul...
Pas de changement majeur (seulement le premier include a changer (car j'inclus un fichier qui configure mon include_path... etc ).
Et pour le serveur, c'est à toi de faire pointé dessus donc ca change quasiment rien.
En gros, ca change rien ou presque (pour moi)
Hors ligne
Je dirais que toutes ces solutions sont bonnes à prendre.
Personnelement, j'ai tendance à utiliser une architecture modulaire (voir http://framework.zend.com/manual/fr/zen … dular.html).
Après tout dépend de la taille de ton projet.
Dans tous les cas, je ne met jamais la library zend ainsi que les fichiers de l'application dans le repertoires /www/ (ou /htdocs/, /public/, etc...) pour des raisons de sécurité.
Je n'aime pas vraiment les htaccess et préfère largement configurer le mod rewrite à partir du fichier httpd.conf d'apache (en effet, un htaccess est éxecuter à chaque requête, tandis qu'une configuration dans le httpd.conf est effectué une seule fois au redémarrage du serveur), de plus, les htaccess pourrait poser certains problèmes de sécurité.
Cependant si tu est en mutualisé avec un unique accès au dossier www, tu seras obliger d'utiliser un htaccess et de mettre tous tes fichiers à 'découverts'.
Hors ligne
Bonjour,
Il n'y a pas vraiment de bonne architecture, ça dépend de la taille de ton projet et de ton hébergement.
L'idée générale et que ton serveur apache doit pointer vers le répertoire où se trouve ton index.php. Si tu ne contrôles pas ta conf apache (un hébergement mutualisé par exemple), il faudra sans doute mettre ton index.php à la racine, sinon il est préférable de le mettre ailleurs.
Par contre si tu décides de changer ton arborescence, les liens de ton site ne changeront pas (tout est intercepté par le ZF et les URL dépendent du routeur). Si tu modifies comme il faut ton include_path, tu n'auras pas à changer ton code. Bref, le choix de l'arborescence n'est pas absolument déterminant pour la suite, choisis l'arbo qui te conviens le mieux.
A+, Philippe
Hors ligne
l'important est d'y avoir réfléchi un peu. une fois cela fait il n'y a plus besoin d'y penser.
la position du fichier index.php n'a aucune importance.
pour moi le dossier public donne accès à tout ce qui est public donc visible hors application. en clair tout ce qui est directement accessible par une url sans passer par php. index.php lui n'est pas directement accessible puisqu'il doit être interprété.
donc je ne le mets pas dans public.
mais c'est un choix comme un autre.
voilà ce que j'utilise :
http://sekaijin.ovh.org/?p=3
A+JYT
Hors ligne
Mr.MoOx a écrit:
Perso j'utilise actuellement celle ci
Code:
application/ .htaccess controllers/ models/ views/ layouts/ scripts/ public/ .htaccess img/ js/ css/ index.phpMais jusqu'a assez récemment j'utilisais celle là:
Code:
application/ .htaccess controllers/ models/ views/ scripts/ public/ .htaccess img/ js/ css/ .htaccess index.phpAprès je ne sais pas si y'a de solutions ultimes. Avec un coup de htaccess on peux trouver plusieurs solutions propres je pense.
Mais dans quel dossier se place les différentes librairies ? (désolé pour le UP sauvage)
Hors ligne
ou tu veux, ca depend que de toi... si tu n'a qu' projet met le au meme niveau que application
application/ public/ librairies/ Zend/ LaTienne/
Après si tu l'utilise sur plusieurs projets comme moi, tu le met à des niveaux au dessus, puis c'est qu'un historie d'include_path
Hors ligne
Concernant la place du bootstrap (index.php), il y a un élément à garder en tête : son but est de restreindre au maximum la quantité de source exposée dans l'espace web.
Autrement dit, la bonne pratique consiste à faire pointer son DocumentRoot (pour Apache) sur le dossier qui contient le bootstrap, et laisser tout le reste (notamment application/ et lib/, mais aussi config/, la bdd etc.) en dehors de l'espace web.
Conclusion, l'arborescence typique (j'ai bien dit typique, pas la seule acceptable bien sûr ) d'une application Zend Framework (mais ceci est valable aussi pour tout autre framework/application) est la suivante :
application/ controllers/ config/ db/ <=== si SQLite par exemple models/ views/ layouts/ scripts/ lib/ XYZ/ <=== pour stocker toute autre librairie propre à l'application (ou tierce partie bien sûr) Zend/ <=== Pour les sources de ZF, mais elles peuvent aussi bien être ailleurs public/ <=== DocumentRoot .htaccess img/ js/ css/ index.php
Avec bien sûr l'alternative, pour une application utilisant des modules, d'intercaler un dossier modules/default/ dans application/.
En bref, dans le meilleur des mondes, index.php doit être le seul script accessible directement http://toto.com/script.php. Tous les autres doivent se situer en-dehors de cet espace, traditionnellement soit dans application/ soit dans lib/
En espérant que ce soit plus clair ainsi :p
Dernière modification par gauthier (02-10-2008 15:18:16)
Hors ligne
Tout est très clair pour ma part, merci à tous :-)
Hors ligne
Concernant la place du bootstrap (index.php), il y a un élément à garder en tête : son but est de restreindre au maximum la quantité de source exposée dans l'espace web.
Autrement dit, la bonne pratique consiste à faire pointer son DocumentRoot (pour Apache) sur le dossier qui contient le bootstrap, et laisser tout le reste (notamment application/ et lib/, mais aussi config/, la bdd etc.) en dehors de l'espace web.
même chose
Hors ligne
Bonsoir,
J'utilise l'architecture suivante
application/ libraries/ nom_application1/ config/ config.ini init.php -----> Bootstrap controllers/ AuthController.php IndexController.php ErrorController.php GnagnagnaController.php models/ lib/ views/ helpers/ layouts/ layout.phtml trucbidule.phtml scripts/ auth/ index.phtml error/ index/ index.phtml header.phtml footer.phtml menu.phtml nom_application2/ idem donc public/ nom_site1/ images/ css/ js/ ajax/ tools/ index.php ----> pointe vers init.php de la bonne appli (rien d'autre qu'un include) nom_site2/ idem
Donc je ne met vraiment aucune source dans la partie "public", l'index pointe vers le fichier application/nom_appli/config/init.php qui est en fait le Bootstrap.
A+
Benjamin.
Hors ligne
c'est une solution qui se pratique aussi en effet. Son intérêt est toutefois limité si l'on place l'intégralité du code de démarrage dans le bootstrap...
Une autre solution consiste sinon, mais elle plus complexe, à recourir à un plugin de contrôleur dérivé de Zend_Controller_Plugin_Abstract, et qui s'utilise ensuite ainsi :
$frontController->registerPlugin(new InitPlugin());
Comme le contenu du plugin serait un peu long à détailler ici (quoique je pourrais peut-être en faire un tuto si ça intéresse quelqu'un...), je peux vous renvoyer vers le squelette de projet ZF que propose Zend Studio 6.1, qui implémente cette technique.
Elle a entre autres intérêts de faciliter l'exécution de tests unitaires sur les contrôleurs (qui ont besoin d'un environnement initialisé mais sans requête HTTP - pas de dispatch()).
NOTA : je ne fais pas de pub pour Studio, vous pouvez tous le télécharger gratuitement en version d'essai, ce qui est suffisant pour générer un projet de type "Zend Framework" et consulter le code dont je parle ici. Pour le reste, je vous laisse seuls juges :p
Hors ligne
C'est le fameux Initializer ?
Hors ligne
lui-même
Hors ligne
Pages: 1