I'm starting to develop a project that will be quite big (hear lots of files) and I want to have an organization that's different from Symfony's default one: instead of having one dir for all my controllers, another for all my forms, etc, I want to have one dir per functionality, ie a directory for my homepage which will contain the controller, the templates, another dir for the blog page with the controller, forms and templates, and so on.
I tried what was explained in this (old) answer, and it didn't work : my routes weren't recognized, and a php bin/console debug:router showed they weren't listed anymore.
I feel I will have something to adapt in my routes.yaml file, which looks like this for now, and which explains why it doesn't work because it explicitely searches in the src\Controller directory:
controllers:
resource:
path: ../src/Controller/
namespace: App\Controller
type: attribute
I looked in the documentation I found, but I didn't find anything useful (I think I will have to remove the path and change it to something else, but I don't know what yet.
The above solutions are only for differentiating controller and template files. But For Entity, Events, and Forms it will not work.
It seems like you want to separate files for each module or functionality. For example, settings.yaml, controller, entity, forms, events, etc...
For that Symfony provides a Bundle feature. You can create a new Bundle in Symfony and use it as a separate feature. For more details please read this link
Related
What is better practise, to use annotations in Controllers or list of routes in file(s) (e.g. routes.yaml) and more importantly, Why?
I worked on big project, where you had all routes in yamls sorted by categories and every time you created new one, you had to update at least controller and some of files. I did not like it. I am hopefully starting one project and trying to decide what better option. I am considering using annotations, but I do not have enough experience yet to be sure it is right approach.
In my opinion, both are good options, and there are not an absolute truth about it. You should use the one with which you feel most comfortable.
For me, the main difference between them are:
Annotations
Keep simple the process of read and update a route, since the route and controller are in the same file, very close to each other.
You're combining in the same file controllers and routing configurations.
YAML
More difficult to read; each time you need to check the route or params, you need to look for the correct yaml file.
More organised way and separated concepts.
My final preference is to go with annotations, the main reason for that is because I don't like the yaml format at all.
It all depends
for common and simple routes to your AppBundle i suggest annotations, But for other bundles that you might want to reuse i like yaml, but the standard is xml. The reason is that the user of the third party bundle can copy the yaml/xml file, and place it in its appbundle and then he can change it and add his own version to his routing. A nice example is fosUserBundle. Imagine that you dont want a registration form because only the administrator may add new users. In that case you dont want routes to registration and would have to change route configuration
Dynamic routes
Sometimes you also need dynamic routes. SonataAdmin is a bundle that generates dynamic routes. It adds routes for each service that is tagged with sonata.admin.
Let's say I have created a news portal bundle "NewsBundle" with articles, tags, events, lots of relations, quite huge and complex.
Now I want to copy this numerous times and create a Fashion News Portal, Car News Portal, Dog News portal and so on each available though an own domain. The portals differ only in templates, translations and assets. As I want to implement complex reporting, I want all the stuff in a single database and would flag all entities with the respective portal.
My question: How so I organize the code?
First I figured out, I could use routing to have the same application but different bundles for each domain.
Then I found out, that I could extend my master bundle. But it seems as this works only once.
As I did all the routing with annotations, it look like it does not work to inherit the routes from the master?
One of the hardest questions is where to put the portal switch. Somewhere I need to set a variable that tells whether its the fashion or dogs portal, so I can filter the content in all repositories accordingly.
I did that in the app.php which is for sure worst practise.
In the end I want to be able to roll out new portals easily without duplicate code.
Any ideas are much appreciated.
Greetings from Hamburg,
Boris
You need to keep your NewsBundle in your application, and to have a number of bundles revolving around it, one for each portal you intend to create.
There is no real need for bundle inheritance here. Your portal bundles depends on the NewsBundle but don't inherit from it.
Routing configuration, templating, and other behaviours related to a specific portal should go in the related bundle. There is a Resources folder in each bundle ; this is where you will need to put specific routing, translation, configuration and templates.
app/config/routing.yml is the central routing conf file where you will need to reference all other routing.yml file.
As for the switch, well, I can't answer that in detail but I think it should be set up in your server application apache or nginx (or other...).
Your problem can be solved via different environments. Each of your portal is a different environment. You can set up your web server to point different front-controllers depending on the domain requested.
Example:
For domain news.domain.com your front-controller would be web/app_news.php. And it will contain line:
$kernel = new AppKernel('news', false);
It will automatically load config from app/config/config_news.yml. In that config you can specify all specific parameters for your portal. You need then just implement your special loader for resources like translations that will load resources from the path specified in config_news.yml.
The page on CSS in the docs http://docs.plone.org/adapt-and-extend/theming/templates_css/css.html#plone-css still suggests using cssregistry.xml, even though the resources are stored in the registry now. Is this the preferred method, as opposed to registry.xml? As far as I can tell it adds them to the plone legacy bundle. Given its name, it sounds like that is something I should be moving away from.
Assuming I don't want to keep using plone legacy bundle, is it bad to add my css/js to the plone bundle or should I create a new bundle for my namespaces?
I have regrouped the following information from a few examples in the SonataAdminBundle documentation. Please correct me if there are some errors, but here is what I get in the case of a BlogBundle:
As you can see, in general, each bundle contains both frontend and backend classes.
It seems very messy to mix both frontend and backend in the same folders somtetimes (see Controllers), but to be honest I can't think of an other way...
I actually started handling backend in a separate bundle but then realised that it was also too messy.
So in practice, do people really follow this architecture? Is this the only/best way to handle backend when using SonataAdminBundle?
This beautiful post here is using a different approach...any ideas what I should do to make sure the code doesn't get too messy.
Simple: use folders within locations of mixed content. I put frontend components directly in their respective folders, and add Admin folders for backend files.
You can refer to e.g. a controller in the Admin subfolder like this BlogBundle:Admin\Concert:index, essentially the same works for templates.
On configuration, you could create a config-frontend.yml and a config-backend.yml file, then include it in the original config.yml file. I don't do that though.
I want to learn is it possible to add additional folder to Controller folder. My reason is pretty simple: I want to divide my project administration and client sides.
Example: I have a controller named Post that has actions Index, Details, Delete, Create, Edit. I want to make one controller as user controller that will consist of Index, Details and another controller as admin controller that will consist of Delte, Create, Edit. Then I will be able to easy distinguish what is what and put admin validation on whole admin class.
Another reason is that I want my url for administrating my site to look like /admin/post/delete, not /post/delete.
So is it possible, and if so then what would be the best way to implement this?
Sound like you want to use MVC Areas? http://www.c-sharpcorner.com/UploadFile/b19d5a/areas-in-Asp-Net-mvc3/
It's just a convention on placing controllers in Controllers folder.
Actually MVC finds controller in current loaded assemblies.
You can place them even in other assemblies.
So, fell free to create additional folders inside Controllers
If you are using Ruby on Rails, yes, you can. In your routes files, config/routes.rb, add this:
map.namespace :admin do |admin|
admin.resources :posts
end
Go to your terminal and navigate to your project, run rake routes. Now you get your posts controller under admin namespace... and your url will be:
.../admin/posts