Bonjour,

Dans Laravel 4 j'étais entrain de regarder, on a maintenant les packages aux normes PSR-0 & co exactement comme sous symfony2 (dont ils ont normalisés le développement de module, package ou bundle selon les appelations en php), c'est bien...
Mais par exemple dans Laravel 3 nous avions les bundles qui pouvait être une forme de package réutilisable.

Le problème est que là dans nos vendors nous avons les packages mais sous laravel 3 les bundles pouvaient embarquer leur propre controllers, routes, models, views etc...

L'équivalent de ce que l'on a sous l'architecture app/... de laravel en fait.

Mais comment sous laravel 4 nous pouvons séparer notre application de façon modulaire comme on pouvait le faire sous laravel 3 avec les bundles ?

On rentre donc dans une architecture HMVC.

Les packages peuvent représenter plus des services utilisables dans nos controllers, mais sauf erreur de ma part comment peut-on avoir l'équivalent sous Laravel 4 en séparant notre application avec un équivalent d'un bundle admin, un bundle profile etc... par exemple.

Sous FuelPHP ou Symfony2 les vendors représentes des bundles (donc package sous laravel) réutilisable mais comme librairie, service etc... Mais pas comme un module MVC que l'on pourrait répliquer sous d'autres applications.
Du coup nous avons une séparation entre les bundles (packages sous laravel) des vendors et les bundle de notre application qui n'ont pas forcément "exactement" la même vocation.

Je ne sais pas si l'on peut faire la même chose sous Laravel 4 en natif (j'ai vue le package "module" mais je veux savoir si en natif laravel permet cela), car si l'on devait créer un module mvc et l'utiliser à partir des vendors cela serait complètement incohérent surtout dans une optique de développer et d'ajouter des controllers ou views dans ce module.

Je trouve ça stupide que dans Laravel ils aient remplacé les bundles par les packages étant donné qu'ils sont complémentaires mais pas remplaçable. Du point de vue d'un développement sur une grosse application les dev ne vont pas étendre le développement du module dans un package situé dans les vendors si non cela devient un bordel d'architecture.

J'espère que quelqu'un me répondra car j'ai aussi posté sur le forum US de laravel (mais bon certains m'ont répondu à côté de la plaque).

Les vendors représentent les packages "externes".
Tu peux faire des packages "internes" un peu où tu veux. Par exemple dans app/libraries et tu l'ajoute à l'autoload de ton composer.json
Tu peux utiliser le workbench aussi.
C'est moins strict que Symfony.

Je sais que rien ne m'empêche de créer un dossier library par exemple et gérer un peu comme je le souhaite.
Sous Symfony2 je peux faire un peu ce que je veux dans mon bundle car tous les fichiers ou dossier dans un bundle représentent l'équivalent d'une application.

Mais sous Laravel pourrais-tu me dire plus ou moins comment procéder et comment cela fonctionne si par exemple je veux créer un dossier module, comment pourrais-je retrouver l'équivalent de l'arborescence app/ ?

Avec un dossier de config, controllers, models etc...
J'ai testé le la création d'un package dans le workbench en auto génération (en PSR-0 hélas, j'ai cherché comme auto-générer en PSR-4 mais pas trouvé), puis j'ai testé un peu le côté controllers.

Mais je ne vois pas vraiment comment Laravel gère le routing depuis un vendors ou bien si je devais utiliser l'arbo d'un dossier "modules/" que j'aurais créé dans mon application.

J'ai l'impression que sous laravel 4 le routing en rapport à laravel 3 que l'on pouvait exploité dans un bundle a été délaissé pour faire place aux vendors uniquement et le reste se passe dans notre app.

Si tu veux parler juste des routes il te suffit de créer un fichier routes.php et de le charger dans ton serviceprovider.

Après j'ai un peu de mal à voir ce que tu veux faire. Si tu veux avoir la même arbo... tu refais la même arbo... rien ne t'en empêche.

Tu as un package qui permet de gérer des "modules" : https://github.com/pingpong-labs/modules

Hola.

J'ai créer tout un système à la main pour laravel.fr :-)

et c'est plutôt simple : https://github.com/laravel-france/website

dans src j'ai mes modules avec des services providers.

Dans app/config/app.php je charge mes services providers (https://github.com/laravel-france/website/blob/develop/app/config/app.php#L116), et dans mes services providers je charge mes routes : https://github.com/laravel-france/website/blob/develop/src/Lvlfr/Forums/ForumsServiceProvider.php#L17

Qu'en penses tu ?

concernant le package laravel module oui je l'avais vue c'est ce genre d'architecture, mais je suis étonné que quelqu'un ait eu à créer un package pour avoir l'équivalent de ce que l'on avait sous laravel 3.
Car effectivement sur une application d'une bonne envergure et lorsque l'on travaille à plusieurs, les vendors vont servir de repositorie de librairie externe réutilisable.
Tant dis que des vendors dans notre application si l'on veut, vont servir à segmenter le développement de sous partie en rapport à notre application.

@JulienTant je vais regardé ce que tu as fait, c'est exactement ce que je recherche, je vois que tu as gardé la même architecture que sous symfony2 avec le folder src/.

C'est exactement ça, je vais voir comment laravel détecte les routes, j'ai vue que tu avais fait des routes groupés. je vais fouiller. Merci à vous deux

Bah en fait, le dossier src c'est un classique dans le monde du développement, c'est pas spécifique à Symfony2 ;-)

JulienTant :Bah en fait, le dossier src c'est un classique dans le monde du développement, c'est pas spécifique à Symfony2 ;-)

Oui j'avais compris lol mais bon dans le domaine php c'est sensio qui a un peu propagé cette pratique.
Même si ce n'est qu'un nom de dossier.
Perso je préfère des noms de dossier simple et évocateur, mais bon par convention dès fois.

@caouecs: Oui et avant Cakephp, Zend et symfony2 il y avait symfony 1 pour ta gouverne ;) Et j'ai utilisé cakephp et il n'utilisait pas ce nommage de dossier ni zend framework au passage. Tu utilisais src/ avant symfony, et bien tant mieux pour toi si ça peut réconforter ton égo :) Tu veux une médaille ? A bon entendeur.

@caouecs : "J'utilisais src/ avant même que Sensio ne voit le jour, avant Sf2, il y a eu CakePHP, ZendFramework et pleins d'autres..." Oui avant Symfony2 il y avait Symfony 1 certainement ;) et les autres. en php c'est bien sensio qui popularisé cette nouvelle architecture et si tu utilisais src c'est bien pour toi, tu veux une médaille sans doute ? En attendant Fabien Potencier a créé Symfony2 et toi @caouecs tu as du t'arrêter à "src" ;) not more.