[Design] Organisation des bundles

Hop,

Petite question design sur l'organisation des bundles. En effet on nous dit de faire des bundles génériques c'est bien on peut les revendre. Donc lorsqu'on développe notre application, on fait nos bundles de façon générique, super.

Mais pour notre application, on a besoin de truc pas générique, on a besoin de personnaliser nos propres bundles ! Ma question c'est donc : comment organiser nos bundles sachant :
* qu'on a des bundles extérieurs. Logiquement on les met dans vendors/bundles, mais ornicar dans son lichess ( https://github.com/ornicar/lichess ) il en met aussi dans src. Une idée du pourquoi ?
* qu'on a nos bundles de personnalisation des bundles extérieurs : on les met dans src/vendors/FOSUserBundle ?
* qu'on a les bundles de notre application, en version générique. On les met dans src/Chess/PremierBundle ? (avec Chess le nom de notre appli)
* qu'on a les bundles de notre application, en version personnelle. On les met dans src/App/PremierBundle ? (avec App un nom arbitraire pour dire "c'est mon appli !")

Ca nous donne :
-- src
---- App
------ PremierBundle
---- Chess
------ PremierBundle
---- vendors
------ FOSUserBundle
-- vendors
---- bundles
------ FOS
-------- UserBundle

Vous en pensez quoi ? Pas facile de se faire une idée, tous les bundles qu'on croise sont indépendants, on a que lichess comme exemple d'application complète.

Pour moi dans vendor c'est tout les librairies ou bundle externe, des éléments qu'on n'est pas sensé modifier mais juste utiliser alors que dans src c'est tout nos bundle qu'ils soit générique : src\nomdunamespace\nomdubundle
ou pas : src\nomdelapplication\nomdubundle

Uhm, soit je comprends pas ta réponse soit on s'est pas compris qq part :p

Si mon appli s'appelle Chess, et que je développe pour cette appli en particulier un bundle SaveGameBundle par exemple. Le namespace de ce bundle est donc Chess\SaveGameBundle, sa localisation est src/Chess/SaveGameBundle.

Seulement j'ai bien travaillé et ce bundle peut sauvegarder n'importe quelle partie de n'importe quel jeu. C'est cool mais moi en l'occurence, je veux qu'il sauvegarde mes parties ChessGame. J'ai donc besoin d'hériter de mon Chess\SaveGameBundle pour surcharger quelques points (entitées, traductions, whatever). Et ma question c'est principalement : comment nommer et où mettre ce bundle de personnalisation ?

bah moi je déplacerais le chess\SaveGameBundle ( si c'est bien ce que j'ai compris le générique ) dans un truc du genre src\Whatever\SaveGameBundle et le bundle de personnalisation prend la place du src\Chess\SaveGameBundle

Dans ce cas t'esquives un peu la question :p Que mettre dans "whatever" alors ?

N'oublie pas que ce whatever sera partie intégrante du nom de ton bundle lorsque tu le distribueras. Il faut donc qu'il soit joli, cohérent, etc. On va pas l'appeler ChessGenericSaveGameBundle ?

On pourrait l'appeler winzouSaveGameBundle c'est vrai, mais dans ce cas tous les bundles que je développe, qu'ils soient en rapport avec Chess/DoctrineExtension/etc, auront le même namespace c'est pas un peu bizarre ? Remarque ca serait peut-être plus logique car un namespace Chess il risque d'y en avoir pas mal, alors que des winzou un peu moins. Donc moins de risque de collision de nom.

Bref, pas évident !

tu peux faire winzou\Game\SaveGameBundle

Voila ce que je crois comprendre (apres; bien loin de dire que c'est la vérité vraie):

Je crois que certaines localisations (src/bundles; vendor/bundles;...) sont surtout apparues avec l'évolution de symfony avec un souci d'organiser. Au début; c'était le bordel (tout dans src) et après sont apparus des bundles génériques (FOSUserBunble).

Il semblerait la version "vendor/bundles/" soit la dernière des éditions pour les bundles distribués/commerciaux si j'ose dire. Encore que c'est assez libre à chacun de le mettre ou il veut.

Le répertoire "src/" resterait la localisation des bundles persos que vous n'utiliserez que pour vous (mais pourrait etre pour plusieurs applications).

Ensuite, comme le propose winzou, l'utilisation d'un namespace lié à une personne ou une société me semble opportun pour les bundles à utiliser dans plusieurs applications... Si c'est pour une seule application, le namespace App(lication) me semble bien.

Enfin; je rappelle que la réutilisation du namespace complet n'est pas obligatoire dans le nom du bunble. il est; je crois; utile uniquement pour des noms trop génériques.

De mon coté; je suis parti sur:

-- src
---- Application ( des bundles par application)
------ MonSite1Bundle
------ MonSite2Bundle
---- ECommerce ( des bundles persos mais utilisables partout)
------ MyCartBundle (le nom peut différer du namespace)
------ TotoLeHerosBundle (pas de namespace dans le nom, personne ne va avoir ca)
-- vendor ( sans s)
---- bundles
------ FOS
-------- FOSUserBundle (comme userbundle est relativement générique, ils ont choisi d'intégrer le namespace FOS dans le nom du bundle)


Je suis à l'écoute de vos idées et conseils!

Malheureusement, ils ont pas "choisi" d'integrer le namespace, ils ont juste suivi la doc ( http://symfony.com/doc/current/book/bundles.html ) qui dit "If you share your bundle publicly, you must use the bundle class name as the name of the repository (AcmeBlogBundle and not BlogBundle for instance)." Tu te retrouves donc avec un bundle ECommerceTotoLeHerosBundle, ouch !

Et du coup dans ton exemple, comment tu personnalises tes bundles MyCartBundle et TotoLeHerosBundle ? Puisqu'ils sont communs a plusieurs de tes appli, voire meme public, il faut bien que tu les personnalises pour chaque appli.

Je crois que je vais finir par mettre tous les bundles que je developpe sous winzouNomBundle dans src. Et puis je les personnalise a chaque fois via un AppliNomBundle dans src/Appli/NomBundle

Pour imager :

-- src
---- Chess
------ ChessGameBundle (perso de winzouGameBundle)
------ ChessUserBundle (perso de FOSUserBundle)
---- winzou
------ winzouGameBundle (le GameBundle generique)
-- vendor
---- bundles
------ FOS
-------- FOSUserBundle (le UserBundle generique)

Et du coup dernier point : on est dans l'appli Chess ici, le bundle winzouGameBundle a ete cree pour cette appli, mais de facon generique (donc utilisable dans d'autres appli). Donc en fait, du point de vue de l'appli Chess, winzouGameBundle est un vendor ! Du coup, on le garde dans src ou sa place devrait etre dans vendor ?

Bonjour à tous,

Je vous expose ma vision des choses :

Le dossier /vendor contiendra tous les 3rd party bundles, que ce soit ceux de FOS ou les notres qui sont réutilisables.

Le dossier /src contiendra seulement le code du Projet càd le projet principal plus les extensions de code des 3rd party bundles (overrides de controller, etc...)
(Si on crée un bundle donc qui ne sera utile qu'à ce projet il sera dans ici)

Les namespaces doivent suivre la convention PHP ainsi ils seront automatiquement gérés par l'UniversalClassLoader:
http://groups.google.com/group/php-s...final-proposal

Evidemment, ceci est personnel 8O

@winzou:
Comme tu le soulignes : "If you share your bundle publicly..."
Or mon TotoLeHerosBundle est perso... donc le namespace n est pas obligatoire... ?

Pour les configurer, tu peux toujours le faire dans la config de ton app!

Maintenant, dans ton cas, si tu comptes partager ton GameBundle, il est alors necessaire de l appeler winzouGameBundle. Par contre, si tu le gardes pour toi uniquement... bah cela ne regarde que toi.

De plus, je dirais meme que si tu partages ton winzouGameBundle. Tu l auras peut etre dans src/ alors que les autres personnes la placeront dans vendor. Cela fonctionnera chez tout le monde; l autoload sera juste un chouya different.

Les questions a retenir seraient donc:
- Je compte le partager?
* oui : je mets le namespace
* non : je peux mettre le namespace
- Ce bundle est il le mien?
* oui : je mets tout dans src/ : c est mon directory de travail
* non: je mets tout dans vendor/bundles: pas touche, ce sont des outils

edit: et cela rejoint creativecwx

En accord avec RapotOR ;)

Pour l'endroit des bundles, ce sont des conventions et non des obligations :

Citation:

---

The UniversalClassLoader is used to autoload files that respect either the technical interoperability standards for PHP 5.3 namespaces or the PEAR naming convention for classes. As you can see here, all dependencies are stored under the vendor/ directory, but this is just a convention. You can store them wherever you want, globally on your server or locally in your projects.

---

Par contre les nom de namespaces est une obligation PHP est d'avoir un espace de nom de top niveau :

Citation:

---

Each namespace must have a top-level namespace ("Vendor Name").

---

Maintenant de là à devoir mettre un vendor name pour des bundles non-publics et non réutilisables ?#@!!!

Citation:

---

Envoyé par RapotOR

Pour les configurer, tu peux toujours le faire dans la config de ton app!

---

Non justement. Quand tu dois changer un chouilla le comportement du controlleur, rajouter une jointure dans une entité, etc... tu es obligé de créer un bundle de personnalisation ;)

Bonjour,

Je vais donner mon sentiment, comme je suis plus pro java que PHP, en terme d'architecture J2EE, on parle de briques métiers avec des services.

Pour moi les bundles vendors sont des briques métiers que l'on active ou désactive en fonction des besoins . ( des jar, ejb + avec services)
Ils doivent donc être indépendants les uns des autres.

dans effectivement tu crées un bundle (src) personnel qui va être la colle logiciel "services" entre ces différentes briques.
et un bundle "main" qui sera la dite application.

bundles vendors (ex UserBundle )

^

|

Client ----> bundle main -----> bundles src -> ORM ou ODM -> SGBD

Pour faire propre, enfin ...
le seul hic, c'est qu'a chaque fois on a modèle MVC, en java, on a pas ce mélange de genre

Confère Architecture J2EE/EJB/JPA

Olivier