I am starting a new symfony web app and i want this project to be as clean as possible. I can't make the decision between routing annotations or base symfony routing in my routes.yml file. Is there any pros and cons to either?
In production, they are both exactly the same - the annotations and/or routing configuration files (be they yaml, xml or php sourced) are all compiled into an optimised regex that is matched from the URL path, to the controller action.
I tend towards mostly annotations on controllers actions (keeping the config close to the actions, as phpdoc annotations), and yaml routing files for the more general other routes, such as redirections.
It is entirely your choice as to where they are put.
Related
I'm working on a complex Symfony project. In the project, we have a core bundle which uses the parameters.yml located in app/config.
Each other AppBundle will inherit this CoreBundle and will correspond to a website.
What I need is to have specific parameters in each bundle that will override the default parameters one: when I'll use a route that will bring me into a controller's bundle, the parameters of this specific bundle have to override all the other ones.
I've tried the preprend method but it doesn't fit to this need. It only allows me to create new parameters for this bundle, but not to override the other ones.
I think you misunderstand the idea of bundles in Symfony. Bundle by design should be a reusable module, therefore the configuration placed inside a bundle is the default one. Then it is possible to override parameters (and not only!) in configuration in app folder.
The basic idea is:
Bundles don't use application. Application uses bundles.
So it's completely the opposite to what you expect it to be. Acutally it makes no sense to condition whole application configuration depending on current route since bundles can use one another. What if your currenct action will internally (without redirect) call another bundle's service or even controller?
Also it's worth mentioning that the app folder is the final folder for your application, therefore you can override in it not only bundle's configuration but also other things like services, view templates and so on.
Edit: I forgot to suggest a solution for you :)
Since you want to use custom parameters inside bundle, why do you need the default value in first place? Just create separate parameter namespace for each bundle that won't be overridden by application config. Then use it only inside that bundle.
Solution found thanks to dragoste's asking about separated kernels.
To solve my problem, I had to split the kernels : one for each website.
Documentation can be found here :
http://jolicode.com/blog/multiple-applications-with-symfony2
Problem:
I’m unsure how to set up multi client application for Symfony so that we would not violate Symfony's best practices and work against the framework.
I would like to have one main Core namespace which would contain all the base model classes. Right next to the core I would like to set up client specific namespaces which would be used, based on client regional setting. For example LocalUS for US market, LocalUK, for UK market etc.
The Local* namespaces should take first priority for including twig templates, and as a fallback use core common shared views (as I understand, this is solvable via twig namespaces). Same goes for controllers and models - these are probably solvable via extending the Core namespaced classes? Is this all solvable via routing and providing paths for these Local* controllers?
I was looking up on github to see if there are any project that have similar setup but I couldn’t find anything.
A little background:
We have an older legacy PHP Application which was built in-house from ground up using plain PHP. As the application has grown over time, it has become hard to maintain good code quality and standards. It’s also very time consuming to teach new developers our application logic, since the application basically follows no standard design patterns and just does it’s own thing. A lot of the underlying code which handles routes, controllers etc seems to work like “magic” that nobody really dares to touch.
It is because of that we would like to migrate our application to Symfony3 framework. I’ve read some articles about the overall process of migrating legacy applications to symfony, and managed to do it with silex pretty well. Silex, however is a bit too lightweight, I found that the assetic service provider had a lot of functionality missing (twig namespacing etc), and decided it would be best if we could move to a full stack symfony framework instead.
Look into Symfony bundles - they do exactly what you need. You create a "base" bundle, than extend it with other bundles. That's how FOSUserBundle works - it provides everything you need, than you extend it and overwrite it.
Is there any way to register bundle's routing from within bundle itself and not importing it in the main routing file?
Now my routing.yml looks like this:
my_route:
resource: "#MyExampleAdhocBundle/Resources/config/routing.yml"
prefix: /
However, I would like to somehow enable bundle routing in ExampleBundle class or bundle config, so it will be on only if bundle is registered in AppKernel.
Have you tried to do this inside your bundle extension file (AcmeDemoExtension for the AcmeBudle) ?
I think you should look inside Kernel::buildContainer to understand how it's done and how you can handle this.
I think custom route loader is the answer.
A custom route loader allows you to add routes to an application without including them, for example, in a Yaml file. This comes in handy when you have a bundle but don't want to manually add the routes for the bundle to app/config/routing.yml. This may be especially important when you want to make the bundle reusable, or when you have open-sourced it as this would slow down the installation process and make it error-prone.
Alternatively, you could also use a custom route loader when you want your routes to be automatically generated or located based on some convention or pattern.
No. For every bundle the routing must be imported in routing.yml. Every popular bundle (like FOSUserBundle) have to do this also.
So no bundle can override users routing. Importing the routes in routing.yml offers the option to define a prefix or host option on this imported routes.
The tutorials I've read for Symfony 2 instructs users to enter their routing information in
app/config/routing.yml
If users want to have routing information in their own bundles, they're instructed to add a routing.yml file to their Bundle, and then point to their file from app/config/routing.yml with something like
my_route_stuff:
resource: "#CustomstuffBundle/resources/config/routing.yml"
Is there any way to skip the "add this extra configuration to the app/config/routing.yml file? I'm looking for the ability to hand off a bundle to someone else, and have them be able to deploy it into their Symfony application without needing to edit their own app/config/routing.yml.
If this isn't possible, bonus point if anyone can explain why (i.e: the general philosophy behind) routing information is part of the AppKernel instead of the individual Bundles. I'm still a little unclear on the differences between routing.yml files and the normal Symfony config.yml files.
Is there any way to skip the "add this extra configuration to the app/config/routing.yml file?
No, this is the way SonataAdminBundle, FOSUserBundle and a bunch of others handle it.
Why?
Routing belongs to the application, not each and every bundle. If every bundle started including their own routing files and Symfony2 autoloaded them, you would quickly have a mess of routes you may or may not want to enable in your application.
What if SonataAdminBundle wanted you to use /admin, but you already had a route there and wanted Sonata to use /sonata/admin instead? You'd need a file to override those routes and then you're back to square one!
Additionally, although caching mitigates this part, looking up files is expensive and would significantly slow down the development environment. This is why translation files are read from cache even in dev mode and you must clear the cache when you add a new translation resource. See: http://symfony.com/doc/current/book/translation.html#message-catalogues
Finally, leaving the routing out of config.yml is simply a matter of organization. Routing and configuration are two different things and don't belong in the same file.
The general idea is that every file is a thing and should only do that thing.
I am little bit confused with symfony2 bundles.
I want to know that does everything in symfony is bundle including main application.
I was thinking as Core of site is somewhere i can write code to use bundles like we use plugins from main application code.
Or there is no core thing in Symfony . The core itself will be bundle
you can define your website completely as a bundle, meaning
Mycompany/MywebsiteBundle
Or you can define the different, sections of your website as different bundle, which i personally preffer
`Mycompany/ForumBundle
Mycompany/BlogBundle
Mycompany/NewsletterBundle`
Symfony2 is bundle-based framework
=> So, everything, as well as the core itself is a bundle.
You can see which bundle is loaded by default in app/AppKernel.php.
But Symfony2 does also include a library, organized by "components (vendor/symfony/src/Symfony/Components). Code in bundle can use this library..
Indeed, everything is a bundle. As per Symfony2 docs:
http://symfony.com/doc/2.0/book/page_creation.html#page-creation-bundles