Discussion :

[goabonga]

Salut,

Je souhaiterais savoir comment vous démarrez un projet.

J'ai l'impression que beaucoup d'entre vous créent un Bundle pour le projet (style Moi\MonProjetBundle ) ? Pouvez vous m'expliquer pourquoi un tel choix ?

[gototog]

Perso j'ai mon bundle métier MainBundle, qui contiens mes entités métiers
J'ai souvent un userBundle quand ma gestion des utilisateurs est secondaire.
J'ai un ImportBundle qui contient mes scripts d'import Excel du client vers la base par exemple, avec seulement les entités qui correspondent à cette gestion: par exemple les paramètres d'import ou l'historique des imports réussis/échoués etc...

Ducoup, on travaille principalement dans le mainBundle, sans être parasité par les entités et par les fonctions secondaires de l'application.

On a pas pour objectif de faire des bundles pour les poser sur github

[goabonga]

Entre nous ces bundles pourraient être privé et hébergé sur vos serveurs avec un petit satis pour faire bien.

J'imagine que tu places les assets propre au projet dans ce MainBundle ? Tu ne travailles jamais dans le dossier app ?

[gototog]

Dans app j'ai juste mes 2 layouts (un layout pour l'utilisateur connecté, un layout pour les erreurs 500, la page de login etc.. donc pour un utilisateur a priori non connecté), et mes pages d'erreurs
Après ce dossier n'est qu'un concentré de configurations (config, cache) et de diagnostique (logs) de l'appli, je me vois pas travailler dedans

[Nico_F]

Hello,

Je vais apporter le témoignage inverse : je n'ai pas de bundle qui regroupe tout le projet et dans la mesure du possible, j'essaye autant que faire se peut de ne pas avoir non plus un mainBundle dans lequel se trouve "le cœur du projet" et encore moins mes classes métier.

J'essaye de faire en sorte que chacune des parties de mon projet soit la plus indépendante possible et donc je démarre avec le premier bundle dont j'ai besoin. Si mon projet contient un blog, je peux commencer par un BlogBundle : les entités métier (articles, tags, commentaires etc.) se trouve dans ce BlogBundle, ensuite je rajoute un espace avec des jeux : je fais un GameBundle, ensuite un autre espace avec un eshop, je fais un EshopBundle etc.

Comme gototog je n'ai pas l'intention de publier publiquement mon code sur github pour en faire des bundle publics, par contre j'aimerais bien pouvoir voir les dépendances de chacun de mes bundles, et le jour ou j'aurai besoin de réutiliser une partie dans un autre projet, j'aimerais qu'il y ait le moins de travail possible. C'est pour cette raison aussi que je ne fais pas de BackofficeBundle par exemple. Chaque bundle possédant des entités ayant besoin d'être managées dans un backoffice contient également la partie backoffice dans ce même bundle. De cette manière je peux (si le couplage avec le reste du projet n'est pas trop fort) réutiliser ce bundle dans un autre projet. et avoir le front et le back de prêts.

Autrement pour réutiliser mon bundle eshop, je dois récupérer mes entités métiers qui selon la méthode de gototog se trouvent dans le mainBundle, mon Backoffice qui selon certains se trouvent dans un BackofficeBundle et le reste du code qui logiquement doit se trouver dans un EshopBundle.

Sinon pour les assets, l'idéal est de les regrouper également par bundle, pour les mêmes raisons que le backoffice, le métier ou autre chose.

Par contre je ne vois pas bien ce que tu veux dire par "Tu ne travailles jamais dans le dossier app ?". Ce dossier contient la configuration de ton projet et de chacun de tes bundles, donc fatalement tu dois mettre les mains dedans mais il n'y a rien en rapport avec la partie métier.

[gototog]

Ah oui, c'est vrai que le contexte est important.
Je travaille sur des applis utilisées en interne par des entreprises, qui n'ont pas grand chose a voir avec du dev web général.
On a jamais de gestion d'article, de news, de parties e-commerces etc.
Le découpement de Nico est tout à fait pertinent (mais ne correspond pas à mon utilisation).

[goabonga]

Merci pour vos retours d'expérience,

Moi, j'ai tendance à commencer par integrer les maquettes que le graphiste me fournit, dans mon cas je place ces éléments dans le dossier app/Ressources/views/ et app/Ressources/public puis j'écris mes routes en utilisant le controller adapté à cet usage (FrameworkBundle:Template:template).

Ensuite, j'écris les tests fonctionnels (behat, phpspec, jasmine....).

Si j'ai besoin d'un blog dans une application j'ajoute le bundle via composer et j'écrase la couche view de ce dernier dans le dossier app/Ressources/BlogBundle/views/Article/..., comme pour les pages d'erreur.

Si je dois ajouter une feature propre a client sur un bundle j'en crée un nouveau qui étendra le bundle cible (ClientBlogBundle).

Si la feature est viable pour d'autres projets je patch le bundle et je laisse composer gérer les dépendances, je crée une nouvelle version ( un nouveau tag v.0.0.3) et j'update les projets où je souhaite faire profiter le client de l'amélioration.

Chaque bundle propose des assets utiliser dans l'application de démonstration des outils de la boite (chaque bundle a même un module js-amd compilé qui pourra être utilisé dans le project client)

Pour la gestion des bundles privés, j'utilise un repository sur le serveur de la boite et satis pour composer.

Si je pose la question, c'est que je suis tombé récemment sur un projet qui avait un bundle Client\FrontendBundle et un autre BackendBundle, je n'ai toujours pas compris la raison, si le dev copie et colle ces deux bundles dans un autre projet il va avoir le thème graphique du premier client de plus le projet global n'est pas une distribution propre à l'entreprise, donc il fait vraiment du copier, coller après avoir cloné la symfony-standard ...C'est problématique pour avoir une vision et un suivi de cette partie du projet.