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.
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.
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.
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.
the core seems to be everything beneath /vendor/symfony/src/Symfony.
There you have three folders:
/Bridge
/Bundle
/Component
What is the purpose of /Bridge and /Bundle?
Also am I right that core means actually two things?
the core library in /Component
the whole setup with caching of routes/config/templates, admin interface, ...
Symfony2 framework is made of: Components, Bridges, and Bundles.
A Component is a standalone library which can be used independently.
A Bridge is a set of classes from one component that extends another library/component. It has been created so components can stay as decoupled as possible. This is also here for a good reason: If you want to use the Form component but do not use Doctrine as an ORM, you don't care about the specific Type created for Doctrine.
A Bundle is a glue between components or Third-Party libraries. The glue of all these components and bridges that make the Symfony2 framework is the FrameworkBundle.
Then, you have the distributions. A distribution is a set of Bundles, third-party libraries and default configurations that makes the installation of Symfony2 really easy for a project.