Zend FR

Salut Manu, enfin quelqu'un qui prend le temps de rédiger ses questions . Je vais essayer de répondre à tout sachant qu'il y a pas mal de choses à dire ^^.

Tout d'abord l'architecture ZF2 fonctionne différemment de l'architecture ZF1 puisqu'on a pas besoin de toucher aux sources du framework (sauf bug etc ...) ou d'aller rajouter des fichiers dedans tu peux donc rester clean sur ce point là. Ceci permet de faire évoluer le framework sans se casser la tête à faire attention de ne pas perdre nos modifications. Ce qui change aussi c'est les modules qui sont au final des briques d'application plus ou moins autonomes. Dans la théorie un module est activé ou désactivé l'application fonctionne toujours sans que ça pose de problèmes seule les fonctionnalités apportées par le module désactivé ne fonctionnent plus. Dans la pratique ça nécessite est rigueur assez important et une très bonne maitrise du framework en passant par des events, des aides de vue etc ... C'est pas toujours simple mais quand on y arrive c'est très beau !

Pour en revenir à ton problème, je pense qu'effectivement tu ne pourras pas redécouper tes applications de la même manière, enfin si tu pourras mais ça ne sera pas forcément dans la logique d'un module. Il y a surement plusieurs façon de faire. Je vais essayer de te donner quelques billes pour que tu puisses te décider.

Tu peux partir sur un découpage fonctionnel avec un module qui va apporter la partie messagerie, un autre la partie gestion utilisateur, une autre le blog, une autre la boutique et enfin le paiement en ligne. Dans ce cas chaque module apporte sa partie mobile, sa partie admin et sa partie classique.
Tu peux partir sur un autre découpage fonctionnel qui serait un module mobile, un module admin et un module classique.
Personnellement je choisirais la première solution ce qui permet d'avoir une application qui plus modulable. Pour une raison X ou Y tu veux bloquer les paiements parce que bug ou problème de livraison etc ... C'est un fichier à modifier et ça désactive tout. En pratique tu auras sans doute une case à cochée dans la partie admin pour le bloquer mais ça reste un exemple.
Ensuite là où j'ai un peu de mal à saisir ton découpage actuel c'est qu'au final tu as des webapp différentes. Si c'est juste des webapps qui répondent à des services rest par exemple les serveurs qui les hébergent n'ont pas besoin d'avoir accès à la partie métier de l'application puisqu'elle sera interrogée via des URLs donc ça peut très bien être sur un autre serveur et en fonction de la webapp les routes sont différentes. (/admin/bidon, /mobile/bidon, /classique/bidon) De ce fait tu as un découpage au niveau de l'application. Après ça peut aussi être la webapp qui récupère partout les mêmes données et en fonction de la webapp va pas forcément afficher les mêmes infos (on peut imaginer moins de fonctionnalité sur la partie mobile par exemple). Dans ce cas là je pense pas qu'il soit nécessaire de développer plus après là c'est à toi de t'organiser comme tu veux.

Dans l'autre cas qui est le cas où les pages sont retournées par le serveur donc on parle plus vraiment de webapp mais ça n'empêche pas d'avoir des ihm différentes. Dans ce cas il faut effectivement tout mettre en module. Je vais prendre bidon-web et bidon-mobile comme exemple.
Bidon mobile va avoir besoin de la même chose niveau métier que bidon-web les seules différences seront dans les vues, donc les contrôleurs (à moins d'aller plus en profondeur et de modifier la vue en fonction de la route : /mobile/bidon /web/bidon). Bref il va y avoir énormément de choses en commun pour cela tu n'auras juste qu'à ajouter les modules dont tu as besoin suivant le découpage que tu auras choisi. Ceci est très simple gérer avec github ou svn. Tu ajoutes un modules depuis le svn, tu travailles sur le module et ensuite tu le mets à jour via svn ou github partout où tu en as besoin.

Ensuite je voudrais revenir sur un point, tu parles d'un module de persistance et de repository et ça il n'y en a plus besoin. Il existe un module ZF2 sur github qui permet d'intégrer doctrine 2 (DoctrineModule et DoctrineORMModule (pour la partie ORM)). Tes répository et tes models seront présent dans le module qui les implémente. On peut imaginer que ton module gestion utilisateur va apporter certains models et donc des repository. Ceci permet d'avoir des modules "out-of-the-box".
De ce fait tu gagnes certains module, tu n'as pas à les redévelopper, tu peux participer pour les améliorer et il n'en sera que meilleur. Grosso modo un module sera découpé par une arborescence de fichiers/dossiers. La partie service dans un dossier service au sein du module, la partie repository pareil etc ...

Dans ton architecture j'ai l'impression que tu découpes comme on a l'habitude de le faire en java avec un module couche service, un module couche DAO etc ... Tu peux faire la même chose sur le ZF2 mais tu perds la notion de module out-of-the-box puisque le module couche DAO ne pourra fonctionne qu'avec une seule couche service tandis qu'avec un module qui gère toutes ses couches tu peux l'ajouter dans une application futur. Imaginons un module de messagerie ça peut être réutilisé partout et surtout si tu as vraiment bien penser à tout et que tu utilises les events (je développe pas trop je maitrise pas très bien les events) si l'event existe (apporté par le module messagerie) alors il sera capturé et des actions seront exécutés; s'il n'existe pas rien ne se passera et ton application fonctionnera toujours normalement. C'est ça qui est génial !

Voila j'espère avoir répondu à pas mal de tes questions. Si tu en as d'autres n'hésites pas, j'ai peut être pas tout compris dans tes problèmes et je n'ai peut être pas non plus été toujours très clair .

goten4 a écrit:

Si je pars sur un découpage fonctionnel de mes modules, avec pour chacun une partie web / mobile / admin, comment est-ce que je dois gérer les sous-domaines ?

Avec les routes tu peux faire des choses assez sympa alors je ne pense pas que ça répondra à tes problèmes.

Ce que je ferais en partant sur ce découpage tu vas donc avoir des contrôleurs et des actions différentes donc tu peux gérer ça via les routes. Tu peux très bien avoir une route mère /mobile et des routes filles /mobile/users, /mobile/admin etc ... Comme ça au niveau applicatif tu peux dissocier les différents contrôleurs. Ce que je n'avais pas pensé c'est qu'au final l'application dédiée au mobile va embarquer tout un tas de contrôleurs dont elle n'a pas besoin. Donc ça peut être intéressant de faire un module spécifique pour chaque webapp.

Je m'explique, comme au final chaque application a le même code source métier (j'entends par là services, DAO etc ...) tu peux peut être partir sur un découpage un peu différent. C'est à dire que tu peux découper de façon fonctionnelle mais ne pas remonter plus haut que la couche service. Tu auras donc tes modèles, tes répository, tes services etc ... qui seront commun. Là je ne pense pas qu'il y ai des comportements bien bien différent. Dans ces modules tu ne mets pas de couche "View" : contrôleurs, template etc ... mais tu fais un module pour ça par application qui contiendra ces actions.

Alors là se pose le problèmes de module out-of-the-box qui peut être résolu de deux manières :
1) soit on oublie
2) soit on essaie de le conserver au mieux

Si on l'oublie, dans ce cas on se pose plus de questions, faut quand même essayer de garder une architecture propre et ça sort un peu de l'ordinaire pour la partie "View"
Si on essaie de le conserver alors il te faudra pour chaque module fonctionnel un module "View" associé à la fonctionnalité.

L'architecture de tes applis ressemblerait donc à ça :
Cas 1 :

ApplicationMobile/
BidonViewMobile
BidonUser
BidonMessagerie
BidonVitrine
BidonPaiement


ApplicationWeb/
BidonViewWeb
BidonUser
BidonMessagerie
BidonVitrine
BidonPaiement

Dans le cas 2 : (ça implique quand même des dépendances entre View"Fonctionnalité" et Bidon"Fonctionnalité"

ApplicationMobile/
BidonViewMobileUser
BidonUser
BidonViewMobileMessagerie
BidonMessagerie
BidonViewMobileVitrine
BidonVitrine
BidonViewMobilePaiement
BidonPaiement


ApplicationWeb/
BidonViewWebUser
BidonUser
BidonViewWebMessagerie
BidonMessagerie
BidonViewWebVitrine
BidonVitrine
BidonViewWebPaiement
BidonPaiement

Sinon, le découpage par couche est loin d'être idiot, je viens aussi du Java et j'aurais tendance à faire pareil. Là il faut prendre en compte la spécificité du ZF2 qui a une architecture modulaire et qui permet de produire des modules out-of-the-box mais dans le cas contraire j'aurais aussi reproduit ce qui se fait en java avec maven 2 ou ant.

En fait c'était pour imager. Dans une application ZF2 tu as 2 endroits possible pour mettre un module : soit tu le mets comme dans le quickstart (qui est le module Album, c'est généralement au même niveau qu'Album qu'on les met), soit tu le mets dans le dossier vendor de l'application.

En général on met dans le dossier vendor des modules externes à l'application genre DoctrineORMModule, ZfcTwig etc ... Dans ton cas tu auras les modules de tes différentes couches. Dans le dossier module on met des modules interne à l'application mais dans ton cas je ne pense pas que ça s'applique puisque tu souhaites mutualiser mais au final ça fonctionne de la même manière que ça soit dans vendor comme dans module. La seule différence c'est que le composer dépose les modules dans vendor.

Donc pour toi tu peux avoir deux architectures suivant comment tu veux procéder.
Cas 1 : (je te met pas toute l'arbo des fichiers)

application-mobile/
    /module
        /BidonViewMobile
        /BidonUser
        /BidonMessagerie
        /BidonVitrine
        /BidonPaiement
    /vendor
        /DoctrineModule
        /DoctrineORMModule

ou

application-mobile/
    /module
        /BidonViewMobile // ici uniquement contrôleur et vue pour toute l'application
    /vendor
        /BidonUser
        /BidonUser
        /BidonMessagerie
        /BidonVitrine
        /BidonPaiement       
        /DoctrineModule
        /DoctrineORMModule

Cas 2 :

application-mobile/
    /module
        /BidonViewMobileUser
        /BidonUser
        /BidonViewMobileMessagerie
        /BidonMessagerie
        /BidonViewMobileVitrine
        /BidonVitrine
        /BidonViewMobilePaiement
        /BidonPaiementmodule
    /vendor
        /DoctrineModule
        /DoctrineORMModule

ou

application-mobile/
    /module
        /BidonBase // ici uniquement un module pour lancer l'application (je suis pas sûr que ça fonctionne sans module
    /vendor
        /BidonViewMobileUser
        /BidonUser
        /BidonViewMobileMessagerie
        /BidonMessagerie
        /BidonViewMobileVitrine
        /BidonVitrine
        /BidonViewMobilePaiement
        /BidonPaiement
        /DoctrineModule
        /DoctrineORMModule

Je sais pas si je suis clair :s

Ok je crois que je viens de trouver la réponse à ma dernière question ...

Dans config/application.config.php, j'imagine qu'il suffit de rajouter les pathes de mes modules :

[lang=php]
    'module_listener_options' => array(
        'module_paths' => array(
            './module',
            './vendor',
        )
    )

Un grand merci à toi pour tous ces éclaircissements, ça m'a beaucoup aidé !

a+
Manu

aromatix a écrit:

quand le module manager va charger un module, il s'arrêter au premier qu'il trouve, ce qui veut dir que si un module toto se trouve dans vendor, et qu'un deuxième se trouve dans module, il chargera celui dans module.

pour le forcer à choir un module spécifique en dev, on peut lui spécifier comme ceci :

Code:

return array(
    'modules' => array(
        'Application',
        'Blog',
        'MonModule',  // <----------------------------------- ton module
    ),
    'module_listener_options' => array(
        'config_glob_paths'    => array(
            'config/autoload/{,*.}{global,local}.php',
        ),
        'module_paths' => array(
            './module',
            './vendor',
            'MonModule' => '/path/to/MonModule',    // <----- on veut charger celui-là
        ),
    ),
);

C'est bon à savoir, merci pour l'info !