I would like to develop a CMS with ecommerce solution on Symfony 2 and Doctrine. I would like to have a Core Bundle for CMS and some other Bundles I could add based on what clients expects.
My question is how to detach Bundles? I mean there are some relations between Shop Bundles and Core Bundles. If I add them in doctrine.orm.yml files with owning side in Shop Bundle and inverse side in Core bundle, then in situation when client wants only CMS (Core Bundle) I don't want to put there Shop Bundle too. If I won't do it, then there will be an error, that Core Bundle has some foreign keys to Table that doesn't exists.
So how to handle it? Maybe database should be designed in a way that nothing from Core Bundle has connection with Shop Bundles? Only vice versa? Or there is a way of doing it with interfaces or sth else? Any ideas?
Related
I have a symfony project.
In the core bundle (the appBundle) I have a User entity.
This project is used by several of my clients, and different clients need different features.
I'm trying to encapsulate a feature in a bundle, but that feature needs to add fields to the User entity in the appBundle.
I'd rather not change the appBundle but rather keep all the changes in the feature bundle.
What's the correct way to do that?
(would creating an entity in the feature bundle to hold the additional fields, and connecting it in a one to one relationship a good idea?)
Assuming doctrine, have you looked into Table Inheritance?
Your AppBundle could provide just a Mapped Superclass and the feature bundles could inherit from it.
Background
We are planning to migrate our current code to a Symfony2 project.
In our case, each application is considered to be a country where we operate. As such:
Each application has a unique top-level domain.
Each application will have the same subdomains.
Each application has its own database. The database structure for each application is the same.
Applications will share the same business logic. Any differences in business logic will be abstracted into a configuration file. There should be a base configuration file that applications can override with application-specific configurations.
Applications will share most of the templates, but there may be application-specific templates too.
Possible approaches
Multiple repos
Each application would be a Symfony2 project by itself.
All development would take place in bundles, each application loading the same bundles thru composer.
This approach would make development quite cumbersome. Ideally I would like to test any changes in all countries without running composer etc.
Multiple apps within a single repo with multiple Kernels
Each application would have its own app in the app/ folder as suggested in here.
Duplicating the whole app folder seems a bit hackish. Not sure if this is a recommended practice?
Modify Symfony2 to support multiple applications
Modify the Symfony2 Kernel/Console/Whatever to support multiple applications.
Are there any existing bundles/examples already doing this?
[Your idea here]
Are there any other possible approaches?
Question
What would be the best approach to add support for multiple applications in Symfony2?
This is a fine approach but if you find you are sharing a lot of code...
The creator of Symfony2 does not recommend this practice. If you need multiple kernels, you most likely need multiple projects. https://groups.google.com/d/msg/symfony-devs/yneojUuFiqw/sZ8BZrzFLbwJ
IDK
For a project I have built the changes come from a $_GET parameter. What I do is, I have a primary project bundle that handles the common functionality and references the app/view for basic layout. Inside the "core" functionality, I created a controller and use it as a service so that all my application-specific bundles can use it at any point. Then I create a Symfony2 extension for each of my application-specific config definitions so that each application can have yml configs while keeping high-level config in app/config/config.yml. An advantage of this is that in the CoreBundle's controller I can create generic page routes and render like:
$this->render('Name'.$project.'Bundle:index.html.twig', array('params' => $params));
It is possible to generate a basic admin interface using the CRUD generator for my Entities.
i.e. php app/console generate:doctrine:crud
The question is, can this also be done for an entity bundled by a vendor? I get errors about not finding the entity I want.
Thank you
It seems that you want to add extra functionality to the vendor bundle so you might need to extend it.
Symfony2 Inhertiance
Which are the best user manager bundles for Symfony 2 and why?
I only know FOSUserBundle.
Are there other good bundles for managing users?
(like it was sfDoctrineGuardPlugin for Symfony 1)
I need not a final, closed solution, but the pros and contras for someone to be able to choose the best bundle depending on his needs.
Firstly, i wrote an UserBundle implementation for my requirements, after i discovered FOSUserBundle and i learned best practices from it.
I think FosUserBundle is a good choice for user manager in Symfony 2. Because
Actively maintained and supported
Provides command line commands for creating new user, activating, promoting etc.
Built-in forms, controllers and views for user related actions.
Supports Doctrine, Propel, CouchDB and Mongo for persistance.
Localization, translations
Optional features like email activation
Supported by other bundles like Sonata bundles
I never worked with other UserBundle, but i highly recommend to use FOSUserBundle.
I'm developing a SaaS where tenants are both real ones and admins (us). So "fornt-end" and "back-end" are the same. Anyway, according to many other questions bundles are a way to structure your project in reusable way.
I really don't think that our bundles are going to be reused, but i still need a way to split the project into bundles to quickly find files we want to work on. Application should:
CRUD for customers - tenants should be able to manage their
customers/partnerships
CRUD for customers tags and keywords (a way to categorize their customers)
CRUD for broadcast notifications sent by us (a messaging system)
CRUD for tenants - we should be able to manage our tenants
So, how can organize my bundles? Could be:
CoreBundle: only Doctrine2 models
ResourcesBundle: templates, js, css, images
SystemUserBundle: manage tenants and customers CRUD
MessagingBundle: message system
How this design can be improved?
According to the Symfony2 documentation:
In Symfony2, a bundle is like a plugin, except that all of the code in
your application will live inside a bundle. A bundle is nothing more
than a directory that houses everything related to a specific feature,
including PHP classes, configuration, and even stylesheets and
Javascript files (see The Bundle System).
Personally, following this description, I would set up the SystemUserBundle to contain the Doctrine2 model and templates/js/css/images that specifically relate to managing customers, rather than splitting them out into CoreBundle and ResourceBundle. However, splitting your app into SystemUserBundle and MessagingBundle sounds like a reasonable approach.
I like to think of it this way - does the bundle encapsulate some behaviour that I might need or want to plugin to a future Symfony project(s) I am involved in. Customer Management, for example, is something that might apply to any app and be re-used across projects (indeed, this is why the extensible FOSUserBundle exists).
I don't think the Symfony2 docs go into sufficient detail on bundles (yet!) but in case you haven't found all the relevant sections these are the ones I'm aware of:
Symfony 2 Page creation
Symfony 2 The Bundle System
Symfony 2 Bundles best practices