Symfony bundle composition, how do I structure my code when using multiple bundles

Question

I'm looking for some guidance on best practice around how to structure my Symfony 2.0 application. If I have a few bundles (Cart Bundle, Product Bundle, CMS Bundle) and I wish to use aspects of all of these bundles when composing my page how should I best do this?

I can imagine two ways to do this, but am looking for guidance on which (if either) is correct.

1) Expose all of the functionality of my bundles through services, and have these services available to use directly from within twig. This way I can pass my routing request to the most appropriate bundle (so http://myclient.org/User/Account) is passed to the ClientUser bundle to handle, but the base template which has a mini shopping cart in the navigation is able to access the information it needs directly from within twig (I don't need to pass this in)

2) Create a bundle that accesses all the other bundles in order to build up the page (like VendorFrontend or VendorBackend). This would mean that ALL routing requests would be passed to this bundle and this bundle would access the required information for every part of the page before passing off to the template.

The first option feels wrong because I'm not sure if it's even possible to allow Twig to consume services directly (though the service container)?

Second option feels wrong because It's like using a second router, the routes would be being passed into a bundle, which only exists to compose the other bundles (it's a given here that this bundle is tightly coupled to the bundles that it uses). Surely this goes against the concept of a 'bundle' that the code is reuseable.

In this example I'm trying to build a very simple e-com site for demonstration purposes only. I have a base template which will have a primary navigation, mini shopping cart, 'body' and footer. I'm storing this in the /app/Resources directory. I was planning on having all other templates inherit this one and overriding the 'body' area.

Not looking to be spoonfed, just a nudge in the right direction. Thanks.

Answer 1

I think that it's important to get away from the idea that, in order to generate a "page", one has to corral together all the variables that the templating involved might need in order to render, and then pass these into a template. A controller should be doing only the specific thing for the request it's serving, and no more. So if there's a specific product referenced in a URL, fetch the product and pass it into the template. If there's a specific product referenced but it doesn't exist, or shouldn't be shown, you respond with a 404/ 410/ whatever is appropriate. If there's a specific collection, fetch the collection and pass it in. The routing/ controller should be decoding the request - the URL itself, the HTTP method, etc - and translating that into something specific. Anything general and not specific to a particular request doesn't belong there.

It's also important, I would say, to abstract as best you can the bundles you use from Twig templates. I am advocating more that templates "pull" what it needs into them, rather than being pushed in, but this is achieved by the definition of Twig functions within bundles that can themselves, via the DI container, hook into data that may or may not be in the current request, etc. So you make a Twig function that can take as a parameter anything that might change - if it has to do with product categories, let it take a product category object as a parameter.

Essentially the answer is more 1) than 2), but you shouldn't be accessing services directly through Twig - you should be proxying via functions that make semantic sense within the template, that themselves are defined to have services injected into them at runtime, services that you are at liberty to define differently in any new bundles you include or write.