This might be an obvious thing to you but – even after reading through a lot of manuals and blogs – I’m still not sure what exactly should a bundle in Symfony2 represent in a webpage. And it’s hard to guess it from the simple demo applications.
For example: I have a site which is divided into two parts (one is just a 2nd level domain like example.com and another is dom2.example.com). Each of these two parts has some sections of it’s own – sometimes the same (like news) sometimes different.
What would the correct representation of this in symfony2? Should I have
- a
MySite\site1andMySite\site2bundle and do the different sections via different controllers, or - bundles
Site1\NewsandSite2\News, or - bundles
MySite\Site1NewsandMySite\Site2Newsetc.
…or am I getting all wrong at this?
I am also new to Symfony and will follow the results of this question with interest, but for what it’s worth, my take on it is:
A bundle is just that: a group of files, assets, PHP classes and methods, tests, etc. The logic of the grouping can be anything you like. In some cases, it’s really obvious what the grouping is and why it’s been done — for instance, if I wrote a blog system for Symfony2 and wanted to release it, I’d make it into a bundle. That’s the sort of example used most in the documentation.
But you’d also use bundles for anything you wanted to release as one little feature. Say for instance, this bundle which creates default routes for all your controllers. It’s not a fully developed plugin/feature like a blog or forum, but it’s a bit of code that I can easily import into my project, it stays totally separate from everything else, it’s a bundle.
Finally, you’d also use bundles internally to your project, in absolutely any way which makes sense to you.
My take on your specific situation:
Quick and easy:
MySite\MyCode— gets the job done, and maybe you don’t have any logical way to break up the code you’re going to write.If there’s some more unique features between the two sites and you want to separate them out for clarity:
MySite\SharedFeaturesMySite\Site1FeaturesMySite\Site2FeaturesIf you really like everything in its place, or if you have a complex project, maybe:
MySite\MySiteMain(shared features and catch-all miscellany that doesn’t deserve its own bundle)MySite\NewsMySite\Site1FeatureSomethingOrOtherMySite\Site2FeatureSomethingOrOtherI definitely think you want to stick to logical groups of code — so I think your example “bundles Site1\News and Site2\News” and “MySite\Site1News and MySite\Site2News” wouldn’t be the best way to go. Site1 and Site2 are implementations, so making a separate bundle for each site’s news page would seem to be counterproductive to me; you’d want to make one news component and build it to be used in two different ways.
As for your two-domains question, you can either point both domains at the same code, and test within your code for what domain is being requested, or you can check out two copies of the same code and change the configuration files slightly (this doesn’t necessarily violate the idea of DRY because you’d still edit the code in one place, then update both copies.)