Discussion :

[khand]

Bonjour,

Ce qui est dit dans la doc, c'est que tout est Bundle !? C'est bien ca ? Ce qui veut dire que une application est découpée en Bundle. Est ce que je me trompe ? Et est ce que l'on peut avoir d'autres "objets" logiques dans une application Symfony2 ?

Et puis, quel est l’intérêt d'externaliser ces morceaux de bundle (form, entity) ?

Merci pour cet éclaircissement !

[dourouc05]

Regarde un seul bundle : tu y verras un gros paquet de classes. Tu auras donc une quantité énorme d'objets, soit définis par toi, soit envoyés par le framework (la requête, un formulaire, une réponse, etc. : ce sont à chaque fois des objets qui sont passés).

Utilité ?

This gives you the flexibility to use pre-built features packaged in third-party bundles or to distribute your own bundles. It makes it easy to pick and choose which features to enable in your application and optimize them the way you want.

In addition to being a nice way to organize and configure your code, a bundle can extend another bundle. Bundle inheritance allows you to override any existing bundle in order to customize its controllers, templates, or any of its files.

[Guybrush113]

Selon moi il y a deux grand types de bundles, les premiers sont tes applications, typiquement ton frontend et ton backend (comme pour Symfony 1.x si tu connais un peu).
Le deuxième type regroupe les fonctionnalités "transverses", c'est-à-dire la gestion des utilisateurs, un bon exemple cité plus haut.

En gros, avant de développer tu as normalement une bonne idée des fonctionnalités que tu devras mettre en place. Mais la plupart d'entre elles peuvent être génériques et ré-utilisables dans la plupart de tes futurs projets (voir tous). C'est donc celles-ci que tu sépares dans des bundles différents.

Va voir ici, il y a plein d'exemples

[dourouc05]

Selon moi il y a deux grand types de bundles, les premiers sont tes applications, typiquement ton frontend et ton backend (comme pour Symfony 1.x si tu connais un peu).

Arg. Pas d'autre mot. Non, du tout. Puisque tu prends le parallèle avec sf1, va voir ceci : http://symfony.com/doc/current/cookb...l#applications. C'est sûrement beaucoup plus simple de penser comme avant, mais tout a changé : un bundle est une fonctionnalité, autant frontend que backend.

Bundle
A Bundle is a directory containing a set of files (PHP files, stylesheets, JavaScripts, images, ...) that implement a single feature (a blog, a forum, etc). In Symfony2, (almost) everything lives inside a bundle. (see The Bundle System)

[Guybrush113]

un bundle est une fonctionnalité, autant frontend que backend.

Oui dit comme ca, ca reste des fonctionnalités évidemment. Mais je pensais surtout à l'identité de ton projet. C'est-à-dire qu'il y a bien un "endroit" où ton projet est différent d'un autre. En gros c'est des bundles non ré-utilisables ailleurs

[dourouc05]

C'est-à-dire qu'il y a bien un "endroit" où ton projet est différent d'un autre.

Dans un template d'admin, on peut décider d'hériter d'un template spécifique admin, sans aucun problème ; de même, ça doit être configurable pour utiliser un layout global depuis le dossier de l'application. Je ne vois jamais le besoin de séparer les deux, je n'y vois même pas de simplification (au contraire de sf1).

[khand]

Merci je commence à mieux comprendre

Connaissez vous un projet sur Github qui illustre bien cette séparation ?

Merci et bonne journée !

[DanaKil]

Bonjour,

J'ai moi aussi cherché un projet déjà existant qui semblerait implémenter "correctement" cette structure préconisée pour les projets SF2 et je n'ai rien trouvé de satisfaisant. Je me pose également beaucoup de questions sur la séparation de mes bundles, même si j'ai déjà eu des pistes de réponse sur ce forum (merci!) et sur d'autres liens. Le problème c'est que les exemples donnés dans les explications sont souvent assez simples et de nouvelles questions se posent lorsqu'on veut se lancer dans un gros projet.

Par exemple, l'exemple récurrent de "un bundle par fonctionnalité" est le blog. OK, mais on ne parle généralement pas de la gestion des utilisateurs qui sont forcément liés à ce blog. Donc soit on fait très simple et le BlogBundle contient à la fois la gestion des utilisateurs et du blogs, soit on cherche à séparer en UserBundle et BlogBundle. Après il reste à faire un lien entre ces deux bundles, ce qui fait dépendre BlogBundle de UserBundle et gâche donc la possibilité de réutilisation (il y a sûrement une solution à ça, peut être avec les "dependency injections", si quelqu'un peut me dire si c'est la bonne piste à suivre... :-) )

En exemple, pour mon projet en construction, je vais avoir entre autre une sorte de boutique, donc des produits et des clients. Finalement cette boutique est une fonctionnalité à part même si c'est un gros morceau du site, j'avais donc crée un BoutiqueBundle qui contient ClientBundle et ProduitBundle.
Seulement, mes clients sont aussi mes utilisateurs, c'est à dire l'entité utilisée pour gérer la connexion au site (via FosUserBundle) et j'aurai très certainement besoin d'y accéder pour d'autres fonctionnalité n'ayant pas trait à la boutique (stats, etc.). Ca me paraît donc plus propre de faire un ClientBundle à part.

Bref, pour l'instant j'ai un peu l'impression d'éclater mes bundles plus par sentiment que "c'est ce qu'il faut faire" qu'autre chose. Je pense sauf nouvelle découverte (ou aide de votre part) que je vais pour l'instant en rester à une structure du type :

- SiteBundle (qui "centralise les autres bundle, contient les layouts admin/front...)
- ClientBundle (qui gère les utilisateurs et que les autres bundles vont venir utiliser)
- ProduitBundle (qui je suppose supportera aussi les règles d'accès à tel ou tel produit en fonction du profil de l'utilisateur [ce n'est pas vraiment une boutique ouverte, la sélection de produit dépend totalement du profil utilisateur])

puis je rajouterais plus tard un StatBundle, etc. Ce qui m'ennuie, c'est que finalement tous mes bundles vont être dépendant de ClientBundle (cela m'ennuie moyennement en fait car je ne vise pas trop la réutilisabilité pour ce projet mais bon.)

Peut être que je devrais créer un espèce de CoreBundle qui contient des entités assez génériques que les autres bundles vont devoir utiliser : Client/User, Civilite (la table Monsieur, Madame...) qui peut être utilisé par plusieurs entité représentant une personne), etc.

Je suis ce post et tous les autres posts traitant du sujet avec avidité... :-)

[khand]

Bonjour,

Merci pour vos réponses. Si j'ai bien compris, je ne dois pas avoir de logique métier dans mes bundle !?

Je dois donc découper mon application en fonctionnalité générique, c'est bien ca ?

Est-ce une bonne idée de mettre l'ensemble de ma logique métier dans un seul bundle , et ensuite mettre tout ce qui est générique dans des bundles séparés?

Merci pour vos conseils.

Bonne journée.

[dourouc05]

Merci pour vos réponses. Si j'ai bien compris, je ne dois pas avoir de logique métier dans mes bundle !?

Je dois donc découper mon application en fonctionnalité générique, c'est bien ca ?

Plutôt : où voudrais-tu la mettre ? Tu n'as pas d'autre endroit pour stocker ta logique, donc tu la mets dans tes bundles.

L'idéal est d'avoir des bundles aussi génériques que possibles, pouvant être utilisées à l'envi sur n'importe quel site. C'est un très pieux objectif, qui te permet de contribuer énormément à la communauté open source et à tes psychiatres de bien vivre. Si tu peux rester générique sans devoir faire des lourdeurs, alors fais-le ; sinon, abstiens-toi (tu t'en mordras peut-être les doigts après, mais tu pourras refactoriser la fonctionnalité à ce moment-là, quand tu es sûr que les heures passées serviront à quelque chose).