What is the best place to keep your TWIG template and why?
app/Resources/views folder
or
YourBundle/Resources/views
Traditionally, Symfony developers stored the application templates in
the Resources/views/ directory of each bundle. Then they used the
logical name to refer to them (e.g.
AcmeDemoBundle:Default:index.html.twig).
But for the templates used in your application, it's much more
convenient to store them in the app/Resources/views/ directory.
Syfmony Documentation
In Symfony 2, auto generated twig files were located in YourBundle/Resources/views
In Symfony 3, auto generated twig files are located in app/Resources/views
When developing your application, best place is YourBundle/Resources/views. It will be more consistent and probably it will be easier to maintain and eventually, decouple your bundle for installation in other projects.
I find app/Resources/views useful to override other bundle's templates, for example when creating Error pages http://symfony.com/doc/current/cookbook/controller/error_pages.html
It depends of your bundles architecture. The point is to be consistent with your current architecture.
From the official doc:
For most projects, you should store everything inside the AppBundle
If you use a main bundle structure (like a big AppBundle with many small domain bundles) then you probably want to centralize your templates in App or the ressources of your main Bundle.
But if you use a functionnal bundles (like EmailBundle, UserBundle, Invoice Bundle) then you probably want to ignore the symfony best practice and put the concerned twig in these bundles.
Related
Can I reuse my Bundle created in Symfony in non-Symfony project, f.e. Zend? (Or I only can reuse Components?)
What about services from that Bundle?
A Symfony bundle can certainly be included in with other projects, via a composer.json & composer.lock file - it doesn't mean that there is any useful code to run within that bundle however.
If there is useful code as part of the bundle, then you can use it directly, but a Symfony Bundle is just a library that will usually include some Symfony-specific configuration.
Best practice for a bundle is to put any useful, common code, into a separate library (which could be used independently - such as what Symfony calls a 'Component'), and then enable that code (for example creating Symfony services, or configuration) with the bundle configuration.
There have been projects that are Symfony bundles, and also have the configurations for other frameworks as well, such as Silex, and also appropriate Laravel configurations within the same codebase.
When creating a new SF2 project, the project contains an AppBundle by default. Should this be removed like the AcmeDemoBundle?
Symfony best practice
For most projects, you should store everything inside the AppBundle.
http://symfony.com/doc/current/best_practices/business-logic.html
Multiple bundles
I tend to create multiple bundles, e.g. I have these bundles in src/:
MyProjectEntityBundle
MyProjectBackendBundle
MyProjectHomePageBundle
And for reusable components I create a symfony bundle that I put into a git repository and load it via composer using satis. So for example I have some bundles in vendor/:
VendorCmsUtilBundle
VendorImageThumbnailBundle
"Domain Driven Design (DDD)"
I have yet to try this approach (I will soon):
http://williamdurand.fr/2013/08/07/ddd-with-symfony2-folder-structure-and-code-first/
As #Marcel Burkhard pointed out, the AppBundle is where you should put all your application logic according to Symfony best practices. Of course you can throw it away and build your own, but it's definitely not like the Acme Demo bundle.
I disagree with the strategy of splitting Entities and Frontend / Backend in different bundles.
I agree with the strategy of creating your own "utility" bundle(s) so that you can reuse your code in different projects via composer.
According to this well-known article:
https://blog.liip.ch/archive/2011/05/19/symfony2-bundle-structure-a-use-case.html
Is there a fast way to scaffold a bundle with Frontend and Backend subfolders?
I haven't heard of something like that. And I don't see any advantage of it.
This also means I don't think you should have both backend and frontend in the same bundle. Id avise you to make two seperate bundles.
Project\Something\BackendBundle
Project\Something\FrontendBundle
You can do that using app/console generate:bundle
This will result in a Project/Something folder structure with both bundles in the same Something folder.
I have an application written with Symfony and want to merge some small bundles as part of that app.
Regarding the quick Symfony2 bundle tour from Sonata, I need an ApplicationBundle.
quick Symfony2 bundle tour:
There are two types of bundles:
Application Bundle (AB),
Vendor Bundle (VB), that should not be modified inside a project.
The AB directory is where developers implement the project requirements,
An AB can overwrite almost everything from a VB, example: you can redefine a VB template at the AB level.
(Source)
Symfony documentation says about architecture:
The directory structure of a Symfony application is rather flexible,
but the recommended structure is as follows:
app/: the application configuration;
src/: the project's PHP code;
vendor/: the third-party dependencies;
web/: the web root directory
(Source)
But where shall I place it?
There are two possibilities:
app/Application (Sonata EasyExtends places ApplicationBundles here)
src
But what is the right one?
And why are there two possibilities?
The Symfony documentation doesn't cover ApplicationBundle.
Thanks for any hints.
The documentation say that :
Application Bundles (in 2 words, this is important) are stored in src/ directory.
Vendor Bundles are stored in vendor/directory (and came from your composer.json dependencies).
You can (and should) create many bundles for you application.
I am developing a multi-tenant capable Symfony2 solution and was wondering if there was a way to use different translations files for each tenant, as the default translations files at present contain e.g. references to the initial tenant's company name, etc.
I am using the Liip Theme Bundle (https://github.com/liip/LiipThemeBundle) to allow tenants to use our codebase, layering their own design on top, but cannot work out a simple and scalable way to allow them to use their own translations files.
There was talk on the theme bundle git repo about this, but I don't believe anything was ever implemented (https://github.com/liip/LiipThemeBundle/issues/12). Ideally I'd like to follow the directory structure they suggested in that thread, e.g.
root
- app
- Resources
- themes
- <theme name>
- public
- translations (this would be new)
- views
as this would allow us to continue the practice of themes being self-contained git submodules that a tenant can maintain themselves.
I ended up using the directory structure I outlined above, and had a console command which symlinked the translations override file in app/Resources/translations. This command ran during my deploy script, and I then created my own "trans" twig function which checked if an override file should be used.
Not the cleanest, but definitely works the way I wanted.