Oke so I am about to make a website using symfony 2.
Should I just make a "main" bundle that controls/puts together all other bundles?
With other bundles I am thinking of lets say a "gallery" bundle that controls things related to photos, and a "store" bundle that controls a shop part.
What would be best (or atleast good) practice and how would professional teams do it?
According to symfony documentation a bundle should be consistent and closed structure. So, if for example "store" and "gallery" are related in some way (eg. use the same model), then they should be in one bundle (AppBundle, CoreBundle, PlatformBundle - whatever you want). But if gallery is completely separate piece of code and can be easily join to another project - then you should consider exclude it to separate bundle.
I think a good idea is look at some projects on github and look how others handle this.
See the following questions and my answers to them:
Should everything really be a bundle in Symfony 2?
Symfony2 conceptual issue: general bundles vs. specific ones
Basically, in my last projects I'm not using bundles for app specific code; the only exception is for stuff that's hardcoded to be in a bundle — like Doctrine Fixtures — that I put in AppBundle. Everything else — models, controllers, services, form types, etc — are out of any bundle.
Like #Cyprian said a bundle is a set of functionality that can work alone. As it happens while developing we do not always know when things are separate. It comes with time.
Personally, I am working with Symfony2 since Febuary and I never stopped reading the manual and related books to understand more in depth. That helped a lot and is very interesting read, I assure you :)
Here is my top favourites documentation pages, en enlightening blog posts on delicious.
For your immediate question, forget about "frontend" and "backend" as we were doing in symfony 1.x. Just think of Model entities (as in A SINGLE row) and build in one bundle. As your code will grow, you will see how to disassemble and separate in bundles. You just have to keep in mind to separate your functionnalities in small methods and refactor around.
Related
I have an application build with Symfony 3.3 and Twig that will be distributed to more customers. I'm using parameters.yml to customize its behavior and it seems to work well.
Where I have an issue is with twig templates: although the customers will use most of the templates as they are, they'll need to customize some parts like CSS styles, general layout and do occasional design overrides.
The options I have identified are:
Have a full set of templates for each customer. The issue is that the upgrades will be a nightmare as we have to patch each template and account for differences
Customize templates via YML files. The problem is that it gets too complicated soon and the number of parameters is potentially huge
Deliver a set of templates in app/Resources/views and allow the customer to override any of the templates by creating another file with the same name in another folder
Deliver a set of templates in AppBundle/Resources/views and let customers override them in app/Resources/views
Create the application as a Symfony bundle (ie. MyAppBundle) and deploy the application to each customer by including the MyAppBundle via composer. I like this solution a lot, but I do not know whether it is possible to implement is easily.
Do you have any suggestion on how to approach this problem?
I think the best way in your case is to think about the main parts and the customer parts and then build blocks and overwrite all parts that are relevant for the customer for example the CSS or anything else. If you know that there are special part you can build macros for example.
With the Block concept you can predefine the template but the customer has the ability to overwrite that part you've defined with it's own.
With Twig you have a lot of possibilities to solve such a problem.
Drupal 8 use that Theming concept.
https://www.chapterthree.com/blog/twig-concepts-drupal-8-themes-part-ii
Perhaps you can take a look how they have solved that and you can find a good solution for your problem.
I have a series of .NET MVC 5 projects I'll be creating that will be used by different departments in my organization with a central index. I'd like to set up a project that contains the css, scripts, images, layouts, error pages, and eventually forms authentication logic/pages. I would then want sub-projects that inherit all of those things so that I don't have to duplicate them for each.
As far as the url structure goes, I'd want to get to the index like this:
www.companyname.com/AppCentral
And to get to one of the sub-projects (TimeKeeping):
www.companyname.com/AppCentral/TimeKeeping/Home
I currently have one project with all of the Controllers/Views/etc for each sub-project lumped in with one another, which can be cluttered. How can I structure my solution so that one project governs css, scripts, images, layouts, error pages, and authentication for sub-projects, so that I may have better separation between projects without having to repeat code/config?
Those structures may have separate solutions, so I numbered them for easier reference. My apologies if this question has been asked a lot, or is often found in references. I was unsure how to find a concept like this using a search engine.
I suppose you searching for areas that appeared in MVC 5.
If you use them you still have all your base logic and styles in the same project but can customize Views, Controller logic and ViewModels.
I'm creating a menu system using the Tree Doctrine extenion and I want to create a Twig extension to display the menu based on the requested parent node e.g. {% display_menu(side_menu) %}. This function will be in the base twig template (i.e. the menu is on every page of the website).
As I'll be storing the Menu structure with Doctrine, I thought I'd need to access the MenuRepository within the Twig extension so the first problem I came across was getting an Entity Manager into it. When looking for a solution, a few people have said that this is bad practice, which makes sense as a Twig extension is part of the View.
So although there is a solution (linked in similar questions) to my problem, my question is, is there a way I can accomplish it using good practice? Or is there a better way of doing it in the first place?
Making entities aware of any services — including entity managers — is a bad practice. There's nothing wrong about injecting an EM into a Twig extension. Although, I'd rather inject a model manager to a Twig extension, so that the extension is not aware of the persistence layer — it's the job of the manager layer.
So, I'd have MenuManager that's aware of repositores/entity managers and inject it to an extension.
Oke so I am about to make a website using symfony 2.
Should I just make a "main" bundle that controls/puts together all other bundles?
With other bundles I am thinking of lets say a "gallery" bundle that controls things related to photos, and a "store" bundle that controls a shop part.
What would be best (or atleast good) practice and how would professional teams do it?
According to symfony documentation a bundle should be consistent and closed structure. So, if for example "store" and "gallery" are related in some way (eg. use the same model), then they should be in one bundle (AppBundle, CoreBundle, PlatformBundle - whatever you want). But if gallery is completely separate piece of code and can be easily join to another project - then you should consider exclude it to separate bundle.
I think a good idea is look at some projects on github and look how others handle this.
See the following questions and my answers to them:
Should everything really be a bundle in Symfony 2?
Symfony2 conceptual issue: general bundles vs. specific ones
Basically, in my last projects I'm not using bundles for app specific code; the only exception is for stuff that's hardcoded to be in a bundle — like Doctrine Fixtures — that I put in AppBundle. Everything else — models, controllers, services, form types, etc — are out of any bundle.
Like #Cyprian said a bundle is a set of functionality that can work alone. As it happens while developing we do not always know when things are separate. It comes with time.
Personally, I am working with Symfony2 since Febuary and I never stopped reading the manual and related books to understand more in depth. That helped a lot and is very interesting read, I assure you :)
Here is my top favourites documentation pages, en enlightening blog posts on delicious.
For your immediate question, forget about "frontend" and "backend" as we were doing in symfony 1.x. Just think of Model entities (as in A SINGLE row) and build in one bundle. As your code will grow, you will see how to disassemble and separate in bundles. You just have to keep in mind to separate your functionnalities in small methods and refactor around.
As Symfony2 said, everything in the framework is bundle. So, your website will also be a bundle. As far as I could understand from http://symfony.com/doc/current/cookbook/bundles/best_practices.html, bundle represents a feature, and that means everytime I want to add a new feature, I must create a new bundle.
For example, I want to create a website which have Blog features and Event Features. Then I will have 2 bundles, BlogBundle and EventBundle. Every code related to Blog will be housed under BlogBundle, and Event in EventBundle.
My question is, where should I put the homepage? or maybe another page like Contact, About, Terms and Policy, etc...?
See these two questions and my answers to them:
Symfony2 conceptual issue: general bundles vs. specific ones
Should everything really be a bundle in Symfony 2?
TL;DR
Create one app-specific bundle called AppBundle to avoid the hardcore decision making process on where to put and then find an entity.