So I'm finally taking this bull by the horns and moving from 3.4 to 4.x and one of the undocumented (?) steps is that previously, all my code was supposed to live in separate bundles per function on the site (at least this was recommended).
Now, suddenly all my code is expected to live inside one bundle (src) and I understand some already had this approach previously, using only the AppBundle with no subdirectories. Obviously this will mess things up when moving from several bundles into one. For one thing, there are several files called DefaultController.php (one per bundle, as I have a LogBundle, a FinanceBundle, a UserBundle etc.
Is there a nice guide to how this move is best made, what paths need to be changed where etc.? Seems like the symfony guys considered this a small little change and no reason to provide a step-by-step, I find it quite annoying 😐 or perhaps I'm just stupid 😂
According to this guide https://symfonycasts.com/blog/AppBundle no code changes are necessary, but my app breaks all over the place when moving files into another directory structure, I suspect routes to templates will need modification, routes to controllers etc.
It also seems that every single Entity relationship breaks when the path to the entity's php file changes...
Rewireing this is a major job, I don't understand why this isn't adressed anywhere?
And while the site referenced above mentions that up to 4.0 your own code resided in several bundles, it seemes that the sample code from sensiolabs silently changed from ACME/DemoBundle to AppBundle between versions 2.4 (https://github.com/symfony/symfony-standard/tree/2.4/src) and 2.5 (https://github.com/symfony/symfony-standard/tree/2.5/src) without any instruction to change your own directory structure to mimic that back then (https://symfony.com/doc/2.5/cookbook/upgrading.html).
So confused 😂
Currently my directory structure looks like this
Related
Say I'm going to create few microservices: Alpha, Beta, Gamma.
In terms of Application structure using older Symfony version like 2, I'd create a bundle for each service, but bundles are no longer recommended in Symfony 4. So... Should I create separate repositories for every service or still create a bundles in a one App?
If you have different microservices, as in different applications, you will not need bundles. You can keep them in different repositories, but a common practice is to use a so called mono-repository. As the name suggests, with a mono-repository you keep all of the projects in a single repository. This has the benefit that changes spanning all projects can be done more easily and in sync. The drawback is that it requires more effort when managing and might cause additional overhead when building and deploying as it will not be easy to see which service has changed so must likely you rebuild all of them. There are a few books and presentations on mono-repositories you might want to check out. In short, Symfony does not restrict how you manage your services. You can have a single repository for all projects or multiple repositories.
If you want to serve all "services" through the same application, even without bundles, you can do so by using namespaces to separate the logic, e.g. for controllers:
my_app
- src
- Controller
- Alpha
- IndexController
- Beta
- IndexController
This should work out of the Box with the default configuration and even if you deviate you can make things like argument resolvers work by just pointing the configuration to the correct folder. Obviously this will require you to make sure that code is not shared between services should you ever want to extract them into their own application. There are some static code analyis tools that help you with keeping your architecture clean, i.e. make sure Alpha does not use code from Gamma and vice versa.
If you want to separate the apps more clearly by doing something like this:
my_app
- src
- AlphaApp
- ...
- BetaApp
- ...
You can still do that but it will require more manual work and the recipes will not work anymore, requiring you to do manual changes to most configurations and moving around files. How to do it depends on whether you want a shared kernel or a separate kernel for each service, but if you go that route I recommend keeping separate projects in the same repository, as it will probably yield cleaner results and be less work.
You can still create bundles in symfony4 though its not recommended by best practices. see https://symfony.com/doc/current/best_practices/creating-the-project.html
How about, I have a problem and it is before in symfony3 was run in the console:
php bin/console doctrine:mapping:import MiBundle yml
and generated and map an entity of the database but in Symfony 4 the command in the console is always the same, but the bundles are no longer occupied in the latest version so the previous command as it is does not work anymore, Someone could help me...
likewise generate the get and set
When using the new Symfony 4 directory structure without bundles the commands for importing the mapping and creating entities from an existing schema in the DoctrineBundle will no longer work properly. There is currently an ongoing discussion whether to update them, but the Doctrine team considers those tools counterproductive. You are not meant to blindly map the schema 1:1 to your domain model.
The best advice I can give for now is to temporarily create a bundle and then move the resulting files. This is also the workaround suggested in the github-issue regarding this: https://github.com/doctrine/DoctrineBundle/issues/729
The Symfony team is moving some of those commands into their own MakeBundle, but I don't think this command is already in there. Maybe you want to follow their progress.
I've very new to Symfony. Before I've used mostly Laravel.
Lets assume I have an API Key which I want to use here and there thru the project.
It doesn't feel right to store it as a class constant because I can't find any class to keep it in. And it seems pretty dumb to have it in various places thru the app as a string.
Normally using Laravel I would have used a config file specifically for this task.
However in symfony I can't seem to do the same(either that or my google-fu skills are pretty bad). If they are, a simple link to some documentation will do just fine.
So my question is: Where can I store various constants used thru the app?
I'm sorry, but I'm afraid your Google-fu skills let you down this time.
Symfony.com has an excellent article about Configuration: Configuration -
Symfony Best Practices
The common way to save configuration parameters is by using parameters.yml. It supports environment variables as of Symfony 3.2.
The best practice for Symfony 2.x and 3.x:
Define the infrastructure-related configuration options in the
app/config/parameters.yml file.
The best practice for Symfony 4:
Define the infrastructure-related configuration options as environment
variables. During development, use the .env file at the root of your
project to set these.
I would like to have a return on your experience concerning Symfony 2 projects :
Has anyone experience putting all of the projects inside the same enveloppe (each project is a bundle for example). why is it bad ?
Another solution : put the vendor folder somewhere on the server and point to it in all Symfony 2 projects (that means there is no vendor folder in the projects). What do you think about that ?
Thank you
Answer 1
It is bad because you will have a single config for each project, so a single database user etc. Not to mention best practises. There is nothing stopping you doing this, but it has bad news written all over it.
Answer 2
If you put the vendor folder somewhere else on the server you will not be able to have different versions of external libraries per project, which is actually important.
If you have common services that more than one project use then I would consider setting up APIs for each services so other projects can access it. OR you could import that bundle.
I started converting a legacy app over to symfony, my first experience with a php framework was zend, learning zend 1.* to a point where I felt comfortable took me over a year, now I've challenged myself to learn symfony since I find zend 2.* overly complicated.
With zend I was used to just creating a controller class and the view to create a page. With symfony I have to create the route entry, then the controller class and finally the view.
My routes.yml is over 100 lines long with all the requirements, methods and whatnot, and I am about a third into the project.
How can I keep this file organized? Right now it looks very chaotic.
Your site should be split into bundles that represent the section of the site that it concerns (from the site I am currently working on)
AddressingBundle
ChartBundle
ContactBundle
CoreBundle // A bundle that contains all merging items (model, types, etc)
CustomerBundle
PaymentBundle
PolicyBundle
.. etc ...
NOTE: I use YAML for routing. Annotation are available that require no extra files but (possible) means lack of reusability of routes
Within each of those bundles is a set of routing files that can be included or not. Each bundle has a routing file located at Resources/config/routing.yml that links to a selection of files located in Resources/config/routing/.
Then for the main app/config/routing.yml file I can then link to the outer (Resources/config/routing.yml) or internal (Resources/config/routing/something.yml) as needs be. Also it enables you to use the same routes multiples times using different paths depending on prefixes.
UPDATE:
The idea of bundles is to separate concerns. So for me I have (which I have massive stolen from the make up of Sylius) the CustomerBundle that only has a single entity (Customer), then I have the AddressingBundle with a single entity (Address). These can work alone but are attached using the data in CoreBundle. This way if I need to edit the Customer section I just edit CustomerBundle and make sure it interacts in the same way. Technically there is not public and private bundles (due to them all being below root), there are only routes that you make public via your routing and security.