Zend FR

Splyf · 15-01-2014 17:31:58

Bonjour,

débutant sur ZF2 j'ai lue le tutoriel "officiel", qui propose de crée un module "Album" .
J'aurai deux questions:

1er question
Pour moi l'exemple n'est pas assez complexe pour me permettre de comprendre certaine partie de l'arborescence:

Par exemple pour la couche "view", on a

Album/View/album/album/index.phtml
Album/View/album/album/add.phtml
ect...

Pourquoi cette profondeur? quel autre type de fichier .phtml ou arbo pourrions nous ranger dans /View/album et View/ tout cours?

Autre exemple, avec les src :
Album/src/Album/controller
Album/src/Album/model

Pourquoi ne pas mettre les dossier controlleur et model directement dans Album/src/ ?

dans le cas d'un module assez simple recoupant que quelque table et une 10aine de vue, quel risque avons nous à simplifié cette arborescence, même en cas d'ajout de classe utilitaire ou métier?

J'aimerai vraiment la simplifier car elle me pique les yeux a l'usage ,mais avant j'aimerai savoir ce que je risque ou perd.

Deuxieme question:
Imaginons le cas classique du application backOffice/frontOffice.
Le frontOffice serai le module application
Le backoffice serai un module "Admin"

Disons maintenant que j'ai une BDD comprenant une table "produit".
Je créai donc un module "produit" comprenant le model ("produit" et "tableProduit").
Par contre Comment géré mes vue? dans le module produit pour le frontOffice et le backOffice, ou alors plutôt dans chaqu'un des module correspondant, ou un peut des deux, voir des trois?

Si vous aviez des exemple...merci d'avance!

Orkin · 17-01-2014 10:01:48

Salut, désolé pour le temps de réponse !

En fait tu as pour la couche view tu as donc :
Album/view/album/album/vue.phtml ceci correspond à NomDuModule/view/nomdumodule/nomducontroler/action.phtml

Donc là c'est essentiellement pour te repérer facilement tu sais tout de suite où trouver telle ou telle vue en fonction du contrôleur et de l'action. Tout ça est vrai uniquement si tu respectes les conventions de nommage. Il est vrai que rappeler le nom du module après view est répétitif.

En fait dans view tu peux avoir un peu tous les templates que tu veux on pourrait imaginer ça par exemple :
Album/view/album/mail/mail1.phtml // template pour le mail1
Album/view/mail/mail1.phtml // template pour le mail1
Album/view/album/widget/widget1.phtml // template pour l'aide de vue widget1
Album/view/widget/widget1.phtml // template pour l'aide de vue widget1
Album/view/paginator/paginator.phtml // template pour ton paginator

On peux imaginer un module qui apporte tous les template de mail pour tous tes modules :
ModuleMail/view/module1/mail/mail1.phtml
ModuleMail/view/module1/mail/mail2.phtml
ModuleMail/view/module2/mail/mail1.phtml
ModuleMail/view/module2/mail/mail2.phtml

Après tu peux faire un peu ce que tu veux. Dans le cas où tu respectes les conventions (ça fonctionne uniquement pour les vues des actions), tu n'es pas obligé de préciser le template_map même si c'est beaucoup mieux de le faire. Donc à partir du moment où tu le fais tu es libre. Ca serait peut être juste plus difficile aux personnes qui travaillent avec toi de se repérer dans ton arborescence de projet s'ils ont l'habitude des conventions !

Pour le dossier src c'est un peu le même principe par convention les classes sont chargées automatiquement sous cette arborescence là. C'est à dire que si tu fais les choses de façon simplistes et en restant dans les mécanismes automatiques du ZF2 (autoload des classes en fonction du namespace) il est préférable de garder cette arborescence. Dans le cas contraire tu peux faire un peu ce que tu veux.

Pour ta deuxième question, je ne pense pas qu'avoir un module Application et un module Admin soit une solution. Je suis plus partisan de séparer les modules par fonctionnalité métier. Par exemple dans ton application tu vas avoir des envoies de mail, une gestion utilisateur et des albums. Ca découperait ton application en trois modules :
- Mail
- User
- Album

Dans chacun des modules tu trouveras à la fois de frontOffice et le backOffice comme ça si jamais tu fais des modules génériques sans dépendances tu peux les retirer sans problèmes sans faire planter ton application contrairement à la solution d'un module chargé du backOffice si jamais pour une raison x ou y tu décides de retirer un module optionnel que tu administres via ce backOffice et bien tu vas devoir recoder des choses pour éviter tout plantage.

Splyf · 21-01-2014 15:05:18

Bonjour!

Pas de souci pour le temps on fait comme on peut, déjà merci beaucoup pour une réponse aussi complète!

Je comprend biiiien mieux!! Le tuto de la doc officiel est bien foutu mais l'exemple choisi est finalement bien trop simple pour comprendre de telle trivialité.

Une foi comprise cette arbo /view/nomdumodule/nomducontroler/action.phtml me va parfaitement! Si l'autoload fonctionne comme sa toute seul comme un grand, alors je vais pas le perturbé ^^.

Pour ma deuxième question :
Mon bute était de pouvoir reprendre le Module "Admin" dans d'autre projet.

Je me rend compte maintenant avec un essais que c'est pas du tout le cas vue que mes contrôleur dépende fortement des module comprenant les model >.<

Donc si je comprend bien le mieux serai de faire comme sa:
- Application
- Album
- user, etc...
- AdminTool
- FrontTool

AdminTool et frontTool comprennent des fonctionnalité métier, quelque petite "sous-vue"
Application comprend tout les controlleur du front et du back. C'est mieux comme sa?

3eme question (dsl ^^)

Dans mon projet d'entrainement, j'ai pris le cas d'un client qui m'offre un cas d'école parfait:
des produits ranger en catégorie, elle même ranger en rayon. les produit on des fournisseur, des client passe des commandes.
Comme toute les table sont lié, je me suis dit qu'il falait ranger tout les model dans un seul module, "Catalogue".
Mais par exempe les table concernant les utilisateur se retrouve dans plein d'appli casi toujours sous la même forme!

Donc, est-ce possible de faire des sous-module?
Par exemple pour catalogue:
Catalogue/Categorie
Catalogue/Produit
Catalogue/User

Et le module parent "Catalogue" gérerai les liaison entre chaque sous module. Ainsi pas de risque d'oublié des dépendance pour mon catalogue en cas de réutilisation

Ou alors suis-je obligé de faire ainsi:
Catalogue
Catégorie
Produit
User

Voila, merci pour ton temps! ^^

Orkin · 21-01-2014 17:33:51

Salut, ne fais pas de module admin tu peux le faire directement dans le module en question. Donc la partie admin pour l'album tu le fais dans le module Album.

Pour tes modèles tu peux faire un module Catalogue qui va regrouper tout le catalogue sauf l'utilisateur et un module User qui va gérer les utilisateurs. Ainsi ton module catalogue aura une dépendance au module User.

Splyf · 22-01-2014 11:32:48

mais si je veut centralisé des fonctionnalité et les réutilisé ailleurs?

Comme lorsque par exemple, jai des plugin jQuery, qui on besoin d'un dom html initial bien précis?
Ou alors que je veut toujours le même layout pour tout mes backoffice, avec toujours une adresse qui ressemble à domaine/admin/etc?

Pour le moment c'est les seul exemple que j'ai mais c'est mon cas^^.
Pur le layout par exemple, dans la classe module du plugin admin, j'ais simplement:

Code:

[lang=php]public function onBootstrap($e) {
        // Register a dispatch event
        $app = $e->getParam('application');
        $app->getEventManager()->attach('dispatch', array($this, 'setLayout'));
    }

    public function setLayout($e) {
        $matches = $e->getRouteMatch();
        $matchedRouteName = $matches->getMatchedRouteName();
        // Set the layout template 
        if ($matchedRouteName == "admin") { 
            $viewModel = $e->getViewModel();
            $viewModel->setTemplate('admin/layout');
        }
    }

dans la config de l'admin:

Code:

[lang=php]'view_manager' => array( 
        'template_path_stack' => array(
            'admin' => __DIR__ . '/../view',
        ),
        'template_map' => array(
            'admin/layout' => __DIR__ . '/../view/layout/layout.phtml',
        )
    ),

dans le fichier de config de mon module Album (dans mon cas Catalogue)

Code:

[lang=php]'admin' => array(
                'type' => 'segment',
                'options' => array(
                    'route' => '/admin[/][:action][/:id]',
                    'constraints' => array(
                        'action' => '[a-zA-Z][a-zA-Z0-9_-]*',
                        'id' => '[0-9]+',
                    ),
                    'defaults' => array(
                        'controller' => 'Catalogue\Controller\Admin',
                        'action' => 'index',
                    ),
                ),
            ),

et j'ai un controller adminController dans /Catalogue/src/controller.

Je peut toujours retirer mon catalogue sans tout faire planté, et il peut fonctionner sans l'admin en le configurant correctement.
Movaise idée? j'espère pas parceque j'ai mis un moment pour mettre au points cette structures, après si c'est movais temps pis c'est en faisans qu'on aprend ^^

Dernière modification par Splyf (22-01-2014 11:37:21)

Orkin · 22-01-2014 15:25:44

Salut, en fait pour la partie du layout du peux très bien faire un module Admin qui te gère ce changement de layout pour ton application. Sans te soucier des modules présents et ce module servira uniquement pour gérer l'admin : contrôle sur l'url pour la connexion, contrôle sur l'url pour le layout etc ...

Dans tes autres modules tu peux effectivement faire comme tu as fait des contrôleurs Admin ou simplement faire des actions du genre adminEditAction, adminDeleteAction (dans CatalogueController). Pour les actions spécifiques genre helper, plugin etc ... rien ne t'empêche de les mettre dans ton module admin de ce fait tous tes modules auront une dépendance à celui-ci.

Splyf · 23-01-2014 09:28:59

Okay!

Bon, je pense que j'ai saisi la logique!
La je cherche a me familiarisé avec doctrine 2 et zf2.. Freakin' awesome! Je trouve réponse a mes questions pr le moment mais je risque de rapidement revenir ici lorsque je vais me retrouvé face a des model plus complexe

Merci en tout cas!

Zend FR

#1 15-01-2014 17:31:58

Comprendre l'arborécence de fichier d'un module

#2 17-01-2014 10:01:48

Re: Comprendre l'arborécence de fichier d'un module

#3 21-01-2014 15:05:18

Re: Comprendre l'arborécence de fichier d'un module

#4 21-01-2014 17:33:51

Re: Comprendre l'arborécence de fichier d'un module

#5 22-01-2014 11:32:48

Re: Comprendre l'arborécence de fichier d'un module

Code:

Code:

Code:

#6 22-01-2014 15:25:44

Re: Comprendre l'arborécence de fichier d'un module

#7 23-01-2014 09:28:59

Re: Comprendre l'arborécence de fichier d'un module

Pied de page des forums