I am developing an app with Symfony2 that has 3 main parts called frontoffice, backoffice, admin. I was thinking to create three separate bundles: FrontOfficeBundle, BackOfficeBundle, AdminBundle but Symfony's docs says, each bundle should not have any relation with each other. Entity is already a shared property and probably some models. I could create a SharedBundle but it does not make sense. I remember when I created an app 2 years go when I had like 15 bundles and all connected each other and I know from experience that it's a nightmare.
Should I have just one bundle AppBundle and logic split in the folders, eg. Controller/Admin; Controller/FrontOffice, Controller/BackOffice?
What's the best approach?
It's all about SRP and DRY
It doesn't hurt to create a bundle, so make a separate bundle for stuff you need in multiple bundles, e.g. I tend to create an EntityBundle which contains entities and their repositories (as service).
Of course you can just use a single AppBundle too but please don't put your logic into the controllers -> create reusable services! Inject the services you need into your controller (which should themselves be services too).
Alternatives to base Controller Methods
No such thing as best approach.
However, instead of grouping by class type (Controller,Command,Form,Templates) within a directory, I like to create a single "component" directory for each request action. So I would have
Action
FrontOffice
BackOffics
Admin
User
UserController.php
UserFormType.php
UserTemplate.html.twig
Grouping files in this fashion really cuts down on figuring out where the various files live. Is it the "best" approach? Nope. But it works for me.
Related
I'm refactoring a not-so-complex website based on Symfony 2.2 / PHP 5.3, and the main issue here is repeated code.
There are two bundles, one for the main website, and another with the mobile version. Those differences are not only on templates and static files, as they comprise some differences in business rules and so on.
Currently those two bundles sport three controllers, one being the main guy, another being the exceptions controller, but a third is the "mother-controller", that holds several common methods and behaviours, and is inherited by the actual controllers.
This poses a small problem, since I can't simply make the action controllers of the mobile bundle inherit from the desktop bundle. All I could do is implement inheritance between the mobile's DefaultController and the desktop one... And thus I still have a bunch of actions almost equal, except for some custom lines.
Is there a way to extract those actions to a generic class and them import them into the controllers (like we have in Yii's Action classes)? I searched about using the decorator pattern to no avail, and was wondering if there's any sort of known method to implement this idea.
Since you have two bundles my first idea would be to create another (let's call it "CoreBundle") and create CommonController there and put common logic into it. Then, let other controllers extend this CommonController.
The more cleaner, but harder, solution would be to create service which would be parametrized by needed data/services.
I am quiet new to the symfony framework and took some lessons and purchased the 'Starting in Symfony2' tutorial from knpuniverse. I want to be sure that I use the correct setup for my application. My question is, How do you call your first central bundle? eg. FrontendBundle? I want to make the next structure in my application:
FrontendBundle
The front where people get a landing site where they can also login
from there, when they login, they get into the next bundle:
CustomerBundle
Backend app where customers get their invoices and pay them and edit their information we stored in the database
And at least:
AdminBundle
Another backend app where I can edit customers, make invoices for customers and edit the app information
Is this the correct way and is FOSUserBundle a good bundle for this kind of application?
Bundles have sense only if they can be used in "multiple projects". I mean: if you write code, make it as a bundle and you can't reuse that bundle (for example because bundles, as you described above, are strictly and logically connected to your project) this three bundle separations is totally useless.
So, final answer (that is also a question) is:
Could you reuse FrontendBundle in other projects?
Could you reuse CustomBundle in other projects?
Could you reuse AdminBundle in other porjects?
If you notice that you can't use any or all of these bundles for other project, maybe this separations isn't good.
Why I say that?
Because if they can't be used in separated ways is likely that they should be used togheter so you should keep them togheter.
So I advice to keep them into a single bundle (YourNameYourBundleNameBundle (in that notation, for example)) and to separate the single "areas":
FrontEnd controllers/entities/views
Custom controllers/entities/views
Admin controllers/entities/views
This problem has been discussed at length already. For application specific code either do a single AppBundle or don't use bundles at all.
For the past two months, I've been developing a Symfony2 web application. Now I've been going back through and trying to fix some issues with it, because it's gotten a little out of control and I want to make it easy to maintain.
My application is structured into a series of bundles like this:
src/AppName/HelpBundle
src/Appname/InterfaceBundle
src/AppName/ProductBundle
src/AppName/UserBundle
InterfaceBundle just contains several twig templates for the main layout, and each of the other bundles just extend that, e.g.:
{% extends 'AppNameInterfaceBundle::layout.html.twig' %}
For controllers, each controller directory has two sub directories: User and Admin, for example:
src/AppName/ProductBundle/Controller/Admin/ProductCategoryController.php
src/AppName/ProductBundle/Controller/User/ProductCategoryController.php
Is this the appropriate way to structure a Symfony application, or should it be done differently?
The problem is not very detailed but for what I see I think that what you could do is organize things in a way that AdminBundle and a UserBundle contain a set of generic services that allow you to build controllers reusing them.
Then you could have a series of bundles like ProductBundle that reuse/interact with these services. Use dependency injection in your controllers rather than extending the Symfony's Controller class; this way you can leverage service inheritance and build abstract controllers in your AdminBundle and UserBundle and use them to derive your specific controllers.
More in general I like to structure Symfony applications in a way that for each concern that is cross-cutting the application's domain (e.g. indexing of entities in a search engine, logging, generation of URLs and so on) I like to create a bundle that provides some abstractions to handle it; for each area of the domain (e.g. product management, user management etc.) then I like having a bundle that implements interfaces provided in the abstraction ones and that registers specific services to be used in the provided abstractions. Interfacing can be done in this case through the container's configuration and tagging systems.
The question was pretty generic and so my answer is too, if you want more details feel free to provide more details to your question.
I want to create a blogging system in order to practice symfony2,
but currently I get a bit confused when creating entities such as user or blog.
The reason is the following :
User( or Blog) is commonly used in frontend and backend(admin)
(currently I have considered creating FrontendBundle and AdminBundle)
Entity must belong to one bundle.
Currently I have considered the following methods, but what is the best way
in this case, or please tell me if there is another way.
Create bundle named 'BlogCommonBundle' and define User entity as "BlogCommonBundle:User".
Define all controllers under 1 bundle, such as 'BlogBundle', so
frontend/backend(admin) controllers belong to same bundle.
I think creating a BlogBundle and having multiple controllers for frontend and admin functionality is a good way to handle this. Both controllers would make use of the same entities and repositories, and you can easily firewall your admin actions in the security settings of your application. By keeping everything blog related to one bundle, you maintain good code organization.
The same goes for a UserBundle. It's helpful to remind yourself that a bundle should represent a set of like functionality for an application. So if you have code that fetches blog posts, and allows you to create and manage them, they naturally group together in a single bundle.
I asked a similar question here:
How to share a Symfony2 model with several projects
I went with the 'ModelBundle' approach that contains all the entities, forms, repositories, etc. These are all shared with the FrontendBundle and BackendBundle.
So far I'm very happy with this solution.
What I have is the following db structure(tables):
lists[name,id]
list_items[title,list_id,content]
I've created the needed files and code(the MVC) needed to manage the first table(lists).
I also added the hasMany to the model class. At that point I am stuck.
What I need is a solution for managing each item (basic CRUD, I assume that complex management is just an advanced CRUD that I will find out how to do by myself).
I will be specific: since it's a content that have no place (but the admin) that it will be used by itself, should I -
create a full mvc structure for it? (can or should I implement it somehow[how?] in the lists package?
if not, how can I attach the tables? (since the use is about to be dropped in version 2)
would an element(cake concept/context) will be the appropriate way to create a view for such situation?
ANY insight will be appreciated.
If I undertant correctly, you want to create a CRUD part of this tables by yourself, without bake.
You need to write all the MVC estrucure and be carefull with the naming combention of cakephp http://cakebaker.42dh.com/2006/02/18/cakephp-conventions/
You need the model into app/models and also a a controller into app/controllers (remember naming combentions) and for each model you need a folder into /app/views.
Alfo, every, every function in your controller needs a view, even if this action doesn´t write anything to screen
I hope this was usefull.
Have you tried using Cake's bake feature? Your CRUD will be automatically created in about 2 seconds. I would also recommend you do the Blog tutorial to get a feel for scaffolding.
CakePHP is all about convention over configuration. Eg naming conventions for tables, controllers, models etc.. So much can be done automagically.