Suppose I have an entity.
This is going to be used in two bundles. But I want bundles to be as indepenent as they could.
Where should I place my entity? In another bundle?
This seems like a good place, since my two main bundles are big enough, and when I want to use them in another project (which happened and happens for me), I have to copy both bundles. Not so good for me.
If I put entity in another light bundle, then I have to move a big bundle and a small bundle. Good, but is there a better way in symfony to do this?
Related
I am in trouble to choose the right way to develop my application.
My app will be quite complex and I would like it to be well architectured.
I will have in fact 4 "applications" (adminAPI, clientAPI, frontWebsite, adminArea) and I want each of these "applications" to run on a different server in production.
So my first idea was to create 4 symfony projects. But I have to share a lot of code about entities, forms, validators, buisness logic.
So I see that I can create only one project with one different AppKernel per application. This sound good to me.
Is it the right solution?
If I go for it, should I create also one Bundle per AppKernel to keep things clean and one "CoreBundle" with shared classes like entities, forms, managers and handlers?
Or it is better as said on Symfony Best Practices to keep all in one AppBundle?
As you see I'm a bit confused and I really need your help to create a professionnal application that will grow quickly.
Thank you for your time.
You must not create one project for each area of your application.
With Symfony2 your are to create more than one development environment.
You can create for each of you area one bundle and just decide within the kernel witch bundle should be loaded depends on the environment you have chose.
I would create a "CoreBundle" with all the shared functionality and then use it in the 4 Symfony projects.
Let's say I want to create a Blog in Symfony which lives in BlogBundle. But this BlogBundle has dependencies on other bundles like FOSUserBundle, KnpPaginator bundle, FMBbCodeBundle or whatever I end up using. Does this mean I can't really reuse the BlogBundle in another project. The Best Practices for Reusable Bundles chapter of the symfony cookbook says
A bundle must not embed third-party PHP libraries. It should rely on the standard Symfony autoloading instead.
But what does that mean exactly? Can't I use anything that isn't programmed by me?
If that is the case, I'd have to reinvent the wheel for the most basic problems I encounter in developing my bundle. For example I would have to come up with my own paginator to paginate content, create my own user manager and so on..
I don't see a point in that as I would waste my time fixing problems that have already been done much better than I could do.
Or does the cookbook mean I can't use anything that doesn't live inside a bundle. This would make much more sense to me.
It really irritates me that nobody really has done a blogbundle or something similar that gets good feedback and is mentioned anywhere in the top lists. I know, Symfony isn't meant to have a solution that just works out of the box and some coding is necessary, but still. All the bundles I can find that seem to be very popular are the ones that do something like parse BB Code, take care of User Management and other things that are hard and tedious to do, but never something bigger than doing only one task.
I hope you understand what I mean and can help me with my problem. Thanks in advance!
A bundle must not embed third-party PHP libraries. It should rely on
the standard Symfony autoloading instead.
This means that you shouldn't copy code of other libraries to your Bundle (directory). Instead that you should add them as a dependencies to your composer.json.
I'm new to Symfony and am starting an app which includes an admin section. The general advice is pretty obvious - make an AdminBundle.
However, is that really the best practice? The Symfony documentation is saying that a bundle is intended to be a 'plugin' that can be distributed as is, and will work in another app. Doesn't the admin section need to be aware of all the models and things for the main app though? It's an admin section created to administer changes specifically to my app, so how would it be distributable or self-contained?
I feel like I'm missing something because if all the advice is to make an AdminBundle then I obviously don't understand something or haven't delved far enough into Symfony yet.
I'm just looking to get my app started with the correct structure going forward.
FYI, I created a project with the default AppBundle as well. I was just planning to make everything in there, but that doesn't seem right either as it will be harder to organise all the admin stuff separately.
I think it depeneds on tour needs and size of your project. Creating a special bundle to put there logic for of admin panel is a good practice. But if you have a small application with just couple of entities it's not necessary to create AdminBundle.
Symfony provides you any way you prefer to do what you need. You can create bundle or put all the admin panel business logic into special directory inside your main bundle controller directory or put all code into the same controllers and manage permissions to admin actions by setting up firewall.
I would suggest to use AdminBundle. It lets you keep your code cleaner: a client logic in one bundle, an admin logic is in another.
Bundle description taken from symfony official documentation isn't saying any opposite things. Because if you want you can use your AdminBundle in another app. Bundle is a way to keep different kind of business logic separated of each other.
I am new to symfony and my project is to build a complex web application in symfony.
There will be many small features like pdf export, xls export, document upload which can be used in future projects.
But I am not sure whether I should make separate bundles for pdf, xls, image upload or what.
All I want is that I can reuse the classes. How should I do this?
Start with everything in one bundle. Especially if you do not plan to redistribute the bundle. Using proper separation of concerns when developing your classes will be enough reusability for any of your own projects. You can use namespacing within a single bundle to organize even more. Prematurely separating your project into bundles will add unneeded complexity and there's little, if any, advantage. Save it for a refactor down the road when/if the need for bundles becomes more apparent.
It depends. There is some people who thinks that EVERYTHING goes into a bundle. Personally i think this is wrong, and that the right approach would be to develop small component and have bundles integrate them into the Framework, just like what FrameworkBundle, SecurityBundle etc. does.
For examples on small components you can checkout Vandpibe. Which is just small components/bridges for Symfony2 components.
http://github.com/vandpibe.
I have an application which is developed in Symfony2. Now the structure for it is as follows:
FrontBundle - includes everything related to the application's view and UI.
PersistanceBundle - includes everything related to the persistence layer of the application.
DomainBundle - includes everything related to the entities of the application and the services.
Is this structure ok? Or bundles are used like forum feature - ForumBundle - which includes every layer (controllers, services, domain logic and persistence) related to the forum.
There are no hard and fast rules on how to structure your app using bundles, but here's what I came to after developing on Symfony2 for close to a year.
Use one app specific bundle. At first, I started with multiple bundles like CommonBundle, UserBundle, MainBundle, BlogBundle, ContactBundle, etc. That proved to be not so convenient in the end, so I switched to just one app specific bundle — AppBundle.
You can organize your code neatly using subnamespaces. For example, the backend controllers would go to the AppBundle\Controller\Backend subnamespace.
Note that I'm talking about one app specific bundle — that stuff that's unique to the concrete app and won't make sense to reuse elsewhere. You can still develop separate bundles for reusable stuff and put them into the vendors infrastructure.
Keep non Symfony specific stuff out of bundles. There is no need to have a bundle for the model and the Service Layer classes in a bundle if they are not Symfony2 specific. See this question and my answer for further details.
Like Elnur said, use one AppBundle is a good practice.
A single bundle implements the MVC pattern himself so i think it's not a good idea to use bundles to separate your layers.
I think the best way to use bundles is to think "open source". If the feature you are developping is enough generic to be released for everyone, or to be reused in a future project, place this feature in a bundle.
This way will force you to build the feature without any business rule which belong in your AppBundle.
Bundles are bricks
There are different ways to organise application structure for your projects. But if you want to distribute your bundles and follow symfony best practices, then bundles are more features than separation of UI. More about bundles read in documentation.
I have two projects with the following structures, both valid I think:
making a bundle for each feature: BlogBundle, StoreBundle and so on,
and AppBundle that contains general stuff. No Backend/Frontend
separation. It's SaaS where backend is frontend in most cases.
One bundle for frontend, one for backend. They share only entities
and domain specific stuff. The application has two different ends.