Zend FR

Tu as le post qui résume assez bien les arborescences à utiliser : http://www.z-f.fr/forum/viewtopic.php?id=758. Sinon dans la doc officiel tu as un exemple d'arborescence.

En ce qui me concerne (comme tout le monde le sait sur ce forum, je suis le débutant-boulet) du moment, voici l'arborescence que j'ai choisi actuellement. Ce n'est pas une arborescence définitive mais qui me convient bien pour le moment suivant mon niveau actuel.

/library/        (api de zend v1.2 que je n'utilise plus)
/library1_5/  (l'api de zend v1.5, j'en ai besoin pour les Layout, Form)
/sql/    (mes fichiers sql et uml concernant la bd)
/public/  (les fichiers . A la limite je vais le mettre dans /application
/application/_documentation (la documentation des classes générés par phpdocumentor
/application/_includes/ (contient les répertoires et fichiers des textes FR, constantes, et classes diverses
/application/_models/  (contient tous mes fichiers relatif aux bd)
/application/_templates/ (c'est ici que je souhaite écrire mes fichiers Zend::Layout
/application/module1/Controllers/  (controlleurs du module1)
/application/module1/script/... (contenu d'un répertoire scripts (helper, views...)

Voilà, c'est une arborescence que je n'ai pas encore vu dans les tutos ou post (je ne crois pas), donc je ne peux pas trop te la conseiller). Ce qui me plait dans cette arborescence, c'est que les répertoires précédés de '/application/_' sont ceux utilisés par toute l'application et chaque autre répertoire sont des modules. C'est simple pour travailler en équipe.

Dernière modification par whitespirit (25-02-2008 08:23:17)

Par expérience je déconseille fortement de découper l'application en module en fonction du profil utilisateur

le découpage doit se faire au niveau fonctionnel
Chaque contrôleur représente une unité fonctionnelle, un module est un regroupement homogène fonctionnellement. par exemple le module comptabilité qui va contenir le contrôleur gestion caisse, consolidation des comptes, facturation paye, le module stock lui va contenir le contrôleur des achats, des livraison, gestion entrepôt etc.

par exérience je sais que les droit et les privilège change au cour de la vie d'une application.
mieux vaut donc bien définir les blocs fonctionnels pour attribuer facilement les droite, et gérer les dépendances fonctionnelles

que de définit des modules en fonction des droits ce qui va impliquer de fortes dépendances fonctionnelles et si les droits doivent changer des difficultés d'adaptation.

enfin si les modules sont fonctionnellement bien définit et faiblement couplé il sera possible de les réutiliser d'une application sur l'autre, voire de le généraliser pour en faire un module totalement réutilisable (sans programmation avec simplement du parametrage)

A+JYT