I'm just working through the Symfony2 Bible and I'm a little stuck on the bundle system. It is a great feature but I'm not quite sure how to split my flat PHP application into bundles. It's my first time splitting my PHP code into a full featured MVC framework.
I'm working on a few online games (based on PHP) but how would I define the bundles ? Is it like one single onlinegame1 bundle with all the controllers and functions - Or like a login bundle, a register bundle, a war bundle - summarized one bundle for every single PHP file I got ?
I want to start clean and correct but I'm not quite sure if I understand that feature.
You could think of bundle as an independent reusable component - in most of the cases at least.
Let's imagine a personal blog website. I'd split it into ArticleBundle, UserBundle, CommentBundle and finally MainBundle which would stick all these other bundles together, creating your website. The main point is that you can take for example ArticleBundle and reuse it easily on other project without it being tied to any other bundle.
From Symfony2 book:
A bundle is similar to a plugin in other software, but even better.
The key difference is that everything is a bundle in Symfony2,
including both the core framework functionality and the code written
for your application. Bundles are first-class citizens in Symfony2.
This gives you the flexibility to use pre-built features packaged in
third-party bundles or to distribute your own bundles. It makes it
easy to pick and choose which features to enable in your application
and to optimize them the way you want.
Related
Problem:
I’m unsure how to set up multi client application for Symfony so that we would not violate Symfony's best practices and work against the framework.
I would like to have one main Core namespace which would contain all the base model classes. Right next to the core I would like to set up client specific namespaces which would be used, based on client regional setting. For example LocalUS for US market, LocalUK, for UK market etc.
The Local* namespaces should take first priority for including twig templates, and as a fallback use core common shared views (as I understand, this is solvable via twig namespaces). Same goes for controllers and models - these are probably solvable via extending the Core namespaced classes? Is this all solvable via routing and providing paths for these Local* controllers?
I was looking up on github to see if there are any project that have similar setup but I couldn’t find anything.
A little background:
We have an older legacy PHP Application which was built in-house from ground up using plain PHP. As the application has grown over time, it has become hard to maintain good code quality and standards. It’s also very time consuming to teach new developers our application logic, since the application basically follows no standard design patterns and just does it’s own thing. A lot of the underlying code which handles routes, controllers etc seems to work like “magic” that nobody really dares to touch.
It is because of that we would like to migrate our application to Symfony3 framework. I’ve read some articles about the overall process of migrating legacy applications to symfony, and managed to do it with silex pretty well. Silex, however is a bit too lightweight, I found that the assetic service provider had a lot of functionality missing (twig namespacing etc), and decided it would be best if we could move to a full stack symfony framework instead.
Look into Symfony bundles - they do exactly what you need. You create a "base" bundle, than extend it with other bundles. That's how FOSUserBundle works - it provides everything you need, than you extend it and overwrite it.
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 would like to try Silex but i've some questions.
I know to use Symfony2 and i would like to know if Silex is very different of Symfony or it's the same thing (same operation, same code... ) ?
Moreover, Silex is recommanded for small PHP projects and Symfony for medium or big projects , it's true ?
A few things worth noting:
Silex is based on the Symfony2 components, just like the Symfony2 framework is. As such, it can be considered an alternative user interface to the components (the user being a web developer).
Since they use the same basis, migration between them should be relatively easy.
Just like Symfony2, Silex is mostly a controller framework. It provides you with some structure, but the model and view parts are handled by third-party libraries (such as Twig or Doctrine).
Since your business logic should not be in your controllers anyway, if you separate that code out and keep your controllers light, the limiting factor in terms of project size will only be the amount of routes you have.
That said, Silex will not give you the bundles that Symfony2 has.
Here are some interesting thoughts on when to use Silex (especially in the comments):
https://web.archive.org/web/20160131151109/http://www.testically.org/2011/10/11/is-there-a-specific-situation-when-to-use-a-php-micro-framework-like-silex/
Silex itself is pretty bare, which means that if you want more then just routing and tests you will need to add specific features (DB, Twig ...) in form of Services.
I recommend to take a look at some readymade Plates that provide you with this:
https://github.com/lyrixx/Silex-Kitchen-Edition
or
https://github.com/ivoba/superleansilexplate (thats mine :))
Another point is that Silex has a probably lighter footprint than Symfony2, so if you need a smaller & faster site, Silex is worth a consideration.
(UPDATE) Since Symfony 2.8 You can use symfony 2 as a microframework with a micro kernel controller. See short description here: symfony.com/blog/new-in-symfony-2-8-symfony-as-a-microframework. Now Symfony gives us more control over the structure and architecture. Good alternative to Silex if You prefer the Symfony 2 style.
Comparing Silex to Symfony before 2.8 release
Silex microframework is based on Symfony but it's not exactly the same thing. Using a full-stack framework such as Symfony for a small project is simply overkilling the project.
In a microframework, you have more flexibility to choose the tools you want to use. You can make more decisions about application architecture and logic.
In a full-stack framework with some extend you would have an architecture and a logic already predefined with restrictions and limitations to its configuration.
Silex was designed to build up the tool rather than get the set tools that you might not need. I would say that for small projects in Symfony you would have to remove features - were in Silex you would have to add them.
It is also not true that Silex isn't fit for larger projects. Silex can be used with success for larger projects but remember that you would have to build up your tools to fit your requirements (if you need to customize the architecture and logic - perhaps this is the right way to go). Other than that, I would consider using Symfony instead, because Symfony already has bunch of tools available out of the box.
Bear in mind that:
To conclude, Silex is good for smaller applications and for those, it can surely replace Symfony. Silex can also be used for larger projects (but for larger applications I would recommend to use full-stack framework instead, like Symfony).
Reference for slides at: http://www.slideshare.net/dustin.whittle/silex-from-micro-to-full-stack . If you feel like it, go ahead and read some more about the Silex framework.
I also recommend watching this intro comparing Silex to Symfony: https://www.youtube.com/watch?v=RDVtnsoOysE.
Again, a few Pro for using Silex coming from people who actually use it: https://www.youtube.com/watch?v=OJcdHGJFfLU
Silex is good for small projects, but it can be used for big projects as well. What I like the most of Silex is that I have complete control over my project structure but it's my responsibility if my project is well organized or not.
Also I recommend it over symfony if like me, you moved your application logic to the client side using a JS framework. For me it feels an overkill to use symfony only to serve a few json requests.
Silex is based on the independent Symfony2 components and isn't truly considered a full-stack web application framework like Symfony is. You should only use it for very small projects that only require a few files, or you'll outgrow it pretty quickly.
Silex is a great framework for small as well as big applications. Giving structure to the project is your responsibility in Silex. As the project becomes larger, you can nicely integrate symfony components into it although the documentation for the symfony provider is not so good especially for symfony security component.
Silex is great for prototyping projects. If you know you will be using most of the symfony components then go for symfony because you will end up with integrating almost all symfony components into silex.
In my case I needed speed right out of the box and silex provided me with the speed and although I am using most of the symfony components, it is a lot faster than symfony out of the box.
At the moment I write this, Silex is in maintenance mode and it's end of life occured in June 2018.
Which means you shouldn't use it anymore for new projects.
They recommend you to use Symfony 4 instead.
Silex was really good and fast (maybe faster than symfony 4 for simple requests/requirements), but SF4 may bring some new stack and benefits to our applications.
Update: However, in all of my attempts on migrating from Silex to Symfony 4, the simple services took 4x times more to respond no matter what I do. Silex seems to do a much better job for simple micro services.
Silex is a PHP microframework. It is use for the small project.The coding style of the symfony and the silex is almost similar to the symfony.But the symfony is use for the large projects
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.
As our company starts using Zend Framework as the base framework for most of our projects, we want to share some common elements across all our projects. I talk about things like:
An implementation of a model (based on doctrine2)
RBAC for the model, including user, group, role models
A xml-based templating engine for ajax backend interfaces
(you name it) ...
Basically, all things to put "zend on rails" and get going. What is the best way to package these components? I see two possibilities:
As modules
We include the necessary functions as separate modules into the modules folder.
Pro:
We can set routes and execute code, which is good for many modules (imaginary example: a paypal module needs some kind of callback url. If our module can set it up on its own, no configuration from the "project developer" is needed).
We can provide real functionality (like the user administration) out of the box
We have a bootstrap to set up autoloading and doctrine etc.
Con:
Bad place? Interferes with the users project
A little harder to share between projects (git submodules instead of classpath)
In the library folder
We put it in the library folder and point the classpath to it.
Pro:
Clean solution
Sharing across projects
Con:
Bootstrap has to be explicitly called
No direct routing or actions - everything has to be proxied through the concrete project
So, how do you solve this? Where do you put your reusable, general purpose stuff in zf?
I think you should use both approaches.
When developing "library-like" code, as in kind of "infrastructure" classes and other things that are reusable (like ZF's own components, Doctrine 2's components etc.), you can put them into the library directory. (or its own entirely separate project)
When developing actual ZF modules (like an auth module for example), then format the code around the ZF module structure.
I think by using this kind of approach you get all the benfits you listed, and pretty much none of the cons :)
As one additional idea, if you develop your architecture parts as "services", you could even keep them running as their own web service endpoints.