Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Tout est bundle ?!
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 !
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é ?
Envoyé par http://symfony.com/doc/current/quick_tour/the_architecture.html#understanding-the-bundle-system
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
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.
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.
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.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 ?
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).
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
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).
Merci je commence à mieux comprendre
Connaissez vous un projet sur Github qui illustre bien cette séparation ?
Merci et bonne journée !
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é... :-)
Tu ne pourras pas faire un site correct si tu veux garder une séparation complète des bundles, ce n'est pas possible. Tu dois donc jouer autrement. Tu as parlé de dépendance sur un autre bundle, puis d'injection de dépendances, il me semble qu'il y a là à creuser.
Mais c'est vrai que je n'ai pas encore vraiment trouvé d'exemple complet concret de ce qu'il serait bien de faire pour respecter la philosophie Sf2. Tu peux partir sur ce genre de base : https://github.com/winzou/AssoManager. Mais ce n'est pas encore très complété.
A mon avis il y a certains exemples où tu dois étendre un Bundle générique.
Si on continue sur l'exemple de Blog, par défaut on va dire qu'on des commentaires liés à un article. Mais si tu veux mettre en place des fils de discussions (avec les commentaires) sur les articles, je pense que ca sera plus simple et plus rapide de modifier le BlogBundle, au lieu de créer un Bundle séparé gérant les fils de discussions et le lier au BlogBundle.
Ca reste assez vague pour moi aussi pour le moment ces délimitations, on a envie de prendre les bonnes décisions avant de commencer le projet :p
SALUT !
Ce que je ne comprends pas bien non plus, c'est où placer tout ce qui n'est pas générique ? J'entends par là, tout ce qui est différent d'un blog à l'autre (pour rester dans ce bon vielle exemple de blog) ? Un peu partout dans chaque bundles, ou dans un bundle fourtout ?
Si quelqu'un peu éclairer ma lanterne...
MERCI !
Je pense mettra ça dans mon SiteBundle (voir mon post), ou si on veut vraiment scinder les pages génériques aux pages de fonctionnalités, dans un PageBundle, tout simplement. Un contrôleur par page.SALUT !
Ce que je ne comprends pas bien non plus, c'est où placer tout ce qui n'est pas générique ? J'entends par là, tout ce qui est différent d'un blog à l'autre (pour rester dans ce bon vielle exemple de blog) ? Un peu partout dans chaque bundles, ou dans un bundle fourtout ?
Si quelqu'un peu éclairer ma lanterne...
MERCI !
Tu peux également jeter un oeil ici : http://www.jonathan-petitcolas.com/s...ges-statiques/
---
Note totalement hors-sujet : il n'existe pas encore de forum Twig ? Ca pourrait être intéressant, en tant que sous-forum de celui-ci par exemple.
Bonjour,
Merci pour ce lien
J'ai lu quelque part que Sensio ne voulait plus publier trop de documentation pour éviter que les gens se perdent. (C'était apparemment le cas dans la 1.X).
Cela dit, un petit "Jobeet2" nous aiderait à avoir une vue globale de l'organisation type d'une application Sf2, d'une architecture idéale...
Affaire à suivre j'espère....
Bonne journée !
ps: Pour le sous-forum Twig, je ne suis pas sûr que la quantité de posts concernant Sf2 le rendent nécessaire...
Salut,
Je me joins a la discussion.
Je galère également avec la notion de bundle, et je ne veux pas partir du mauvais pied.
On dit qu'un bundle est une fonctionnalité, comme un forum.
Pour moi un forum est une application composé de "modules" tels que les utilisateurs, les posts, etc ...
Mais j'ai l'impression après avoir télécharger pas mal de bundle que les gens créé un gros bundle et fourre tout dedans, est-ce la bonne manière de procéder ?
Pour en venir a mon cas précis, je veux faire une application avec de gestion de projet internet.
Il y'a des utilisateurs avec differents droits, une gestion des documents, de la facturation...
Alors quoi ? J'ai un bundle GestionProjetBundle ou j'ai des bundles UserBundle, DocBundle, FacturationBundle (oui bon je sais pas dire facturation en anglais :-p) ?
J'aimerai avoir votre avis car que ca soit ici ou ailleurs les opinions m'ont l'air assez divergent.
Merci !
PS : Pour info je suis un développeur Magento, et magento (tout comme Zend) a une gestion par module qui represente des petites fonctionnalités (on a le module utilisateur, panier, catalogue, moteur de recherche ...).
Je pense que c'est aussi ca qui me donne un blocage car je veux me mettre a symfony mais le concept a l'air bien different
En fait on est assez libre dans la gestion des bundles rien n'est imposé.
Le seul principe immuable mais qui n'est pas vraiment lié a symfony c'est qu'il est fortement conseillé de découper ton projet en package réutilisable si tu compte faire d'autres projet qui auront besoin des mêmes fonctionnalités.
Ex : Pour un projet je développe une authentification de type NTLM j'essaye d'en faire un bundle propre pour pouvoir le réutiliser.
Mais pour un autre projet je doit coder une authentification ultra spécifique lié a un besoin très particulier. Dans ce cas tu ne fera surement pas de bundle dédié car cela te prends plus de temps pour faire un bundle propre sans aucun bénéfice en retour.
Pour résumé :
Si ton module peut être assez générique pour être réutilisable et que le temps de le rendre générique n'est pas supérieur au temps nécessaire a le développer pour des projet en cours alors il est rentable de chercher a découper en bundle. (Par en cours j'entends que tu es a peu prêt sur d'avoir dans un temps défini, on est dans la logique si ton module te prends le double de temps a le mettre en bundle propre mais que tu as 3 projet en cours sur le même module bah le choix est facile :p )
Salut à tous,
La question m'intéresse également, je suis en pleine crise existentielle sur ce qu'on met dans un bundle.
Sur symfony2bundles.org, il y a également un page de projets... Peut-être que ça pourra nous aider à voir comment d'autres découpent leurs applis.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager