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.
Related
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
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.
For sample I got these two modules.
Module.Admin
Module.Web
Then, all images that are uploaded inside the Module.Admin is place inside it, sitemap goes like this.
Module.Admin
- Content
-- Uploads
--- Images
Now, how can I load as source these images inside the Module.Web > View .cshtml file?
As I've notice, these two modules are having two different ports. I hope you understand what I'm saying. Feel free to ask. Thank you
Sounds like you made the module a web project too? That means that they will run in seperate sites and not be able to share information.
You should probably use plugins instead. I've described how you can do it in my blog: http://blog.gauffin.org/2012/05/griffin-mvccontrib-the-plugin-system/
If you only want to access files you have to setup a custom VirtualPathProvider which can access the files from the other library.
I'm helping a colleague configure a new box for an existing Drupal install with multiple sites. It's functioning, but I've noticed that all assets are being referenced as /sites/<site-name>/files/image.png. I don't know from Drupal, but it strikes me that Drupal should be abstracting the logical site from the code so that site-specific assets could be referenced as /files/image.png and Drupal would figure out -- perhaps based on HTTP_HOST -- which site is meant.
In this case, we need separate snapshots of the same site (dev and staging) so we'd like to be able to store the paths without specifically referencing one site or the other. We can do some rewriting to manage this, but I'm wondering whether there's something that we simply don't know.
Does Drupal do this natively in some way? If not, what are others doing to manage this kind of abstraction? Surely we're not the first to encounter this and think there must be a better way.
Thanks.
That would be an interesting module. The Files directory can be in the following locations:
sites/<site name>/files (standard for multi sites, public)
or
sites/default/files (standard installation for single sites, public)
That is, if you want to use the public files method.
Read here if you want to learn about the private files method (very similar to your thought): http://drupal.org/documentation/modules/file