Should I create new bundle and use sepparate assets for admin page, or could I just create new adminAction() as page? What would be safer and more correct?
I am not familiar to Symfony2 web structure and want to get better at it. Thanks in advance :)
I have only done a bit of Symfony 2 but the vast majority of project I have seen are using separate bundle for the Admin backend, such as the sonata project
It provides a better separation of concerns, as backend actions are oftenly related to CRUD, when frontend are usually more displays and users managements stuffs (depending on the goal of your project though).
To go further you can also already find bundle similar to the admin backend generator module of symfony (v1), like the symfony2admingenerator
Hope it helped a little.
It depends on your application and there is no "Only one good way". Try to comply SOLID principles and all will be great.
Making many bundles - very bad idea (if you will not reuse your admin-bundle in other projects). You can find info about that in official symfony best-practices
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.
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 have seen lots of pages about Yii Boilerplate setup like: http://www.yiiframework.com/wiki/374/yiiboilerplate-setup-a-professional-project-structure-in-seconds/.
Is there any step by step instruction about creating a new basic YiiBoilerPlate app or maybe I am totally wrong about it!?!?!
Just build your app to fit your needs remembering to keep project specific files in separate folders, separate from base application components, like common extensions. I highly recommend using modules. You can have for example user management module with login, logout, profile etc. functionality, and depending on concrete project requirements just drop in more modules.
Mentioned boilerplate is more complex than standard Yii setup. There is one thing i really dont like, is that mudules are in both frontend and backend, and according to yii philosofy, module should be like mini application, so from this boilerplate seems that one should build separate mini apps for frontend and backend... But it is just a taste what you feel better.
If you are new i recommend standard setup, but using modules from beginning. Modules are something like mini app, which can operate on it's own. This way you can build your portfolio of modules, and then when doing some new project you can compose it much quicker and sturdier. A bit more tricki might be interoperability between modules, but thats a whole different story.
You should refer following article.
http://myprogrammingtut.blogspot.in/2013/04/step-by-step-setup-yiiboilerplate.html
which worked for me :)
Hope it'll help you.
I'm studying the Laravel 3, 1 week ago, but didn't understand everything about the routes.
My main question is: how to create administrative routes?
In the video lessons from Jeffrey Way (Tuts Premium), I could understand two things about it:
Nested Controllers (/application/controllers/admin/user.php)
Bundles (/bundles/user.php) - He did not say much about it.
Anyway, I noticed 2 things (obvious):
On both sides, I can have a route / admin / whatever.
But what the correct way?
I'm really very confused.
Laravel bundles are for developing modular code that you can reuse from application to application in Laravel. The Bundle itself is very much the same as the 'application' directory you have as standard in a Laravel install, allowing you to create modular sub applications within your project. I highly recommend you avoid bundles for the moment entirely and focus on learning the core functionality of Laravel.
For your needs, place your routes within your routes.php file within the application directory and nest them to your hearts content. This will serve your purposes fine. If you're not building/using bundles, you don't need to use bundle routes.
When you're comfortable with Laravels routing and you've built one or two apps you may well have an idea for a bundle that will help you develop your apps faster in the future. This is the time to start learning about bundle routing as it's the only way to link your application logic with your bundle and provide it with a URL schema.
Hope that helps.
Neither way is really right or wrong, the beauty of Laravel is that there are so many ways to achieve the same thing so it's up to the developer to choose what works for them.
Personally I started by using nested controllers as they're much easier to get up and running. I would however recommend making the move to bundles. If you plan on sticking with Laravel (and you should) then it would make sense to build a bundle that includes the auth and components you use in each project already setup. That way you just need install the bundle and you're good to go.
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.