Is it possible to use components from symfony 2.0 in symfony 1.4
project. If so, would you explain how to do it right?
I want to use new Routing in my project.
I would doubt that anything from S2 will work in S1.x. Symfony2 will only work with PHP 5.3 and greater and uses a totally different architecture from 1.4.
As the routing is a key component of the architecture then the chances of it working in a totally different architecture would be vanishingly small. Probably just as well to just use S2 if you want it's routing.
Related
The question:
Is a Symfony 3.4 project created with the Flex installer really Symfony 3.4? Or more a "Symfony 4 project with 3.4 core files?
The complete story:
I am working on migrating an existing Symfony 2.8 project to Symfony 3.4. At first I created a new Symfony 3.4 project using the Symfony installer:
symfony new MyProject 3.4
The file and folder structure is a bit different to Symfony 2.8 but overall everything is quite similar. It was not too difficult to migrate the config, files, etc. from the existing 2.8 project.
However, after some more research I thought it might be a good idea to start the new 3.4 project using the recommended Flex installer instead. This would give me the new folder structure which is also used in Symfony 4, which might make a future migration to this version easier.
composer create-project symfony/skeleton:3.4.* MyProject
Of course the directory structure is different in this project. But not only the folders are different but almost everything. The way the complete config is organized, how the routes are defined and managed, how bundles are organized (none at all), how parameters are defined and used, etc.
There is almost nothing left that looks like Symfony 3.4. This seems to be a Symfony 4 setup where only the files in vendor/symfony/... are from version 3.4
Migrating the 2.8 project to this setup would be way more complex.
Of course I know that a lot has changed in Symfony 4 while Symfony 3.4 is still quite similar to Symfony 2.8. But how is it possible that two Symfony 3.4 installations are so dramatically different?
I understood that Flex is a new workflow to manage projects but shouldn't be the end result - a new Symfony 3.4 project - be more or less the same no matter which workflow / install was used to create it?
Flex is more powerful when setting up and managing different project. However I want to setup the project once and run it for several years. Is there any advantage (in the near future) in proceeding with the Flex approach?
To answer your first question: Yes, a Symfony 3.4 project created using Flex is indeed a 3.4 project. "bin/console --version" will verify this.
As far as the directory structure goes, Symfony tries to strike a balance between maintaining backwards compatibility but at the same time keep moving forward and refining their design. For information on why things were done, it is useful to keep an eye in the Symfony blog and perhaps visit the slack channel. Especially the posts when Flex was introduced as well as the new directory structure.
One goal for Symfony is to make it as easy as possible to migrate from a long term support version to a newer version. Hence 2.8 is pretty much identical to 3.0 except that a bunch of depreciated functionality was removed. If you were following things at the time you would have noticed that there was quite a big jump between 2.7 and 2.8.
Same for 3.4 to 4.0 being easy but a few possible bumps going from 3.0 to 3.4.
Kind of meandered a bit. Sorry.
To address your second question of the value of using Flex, like all opinion based questions the only correct answer is: it depends.
In my case the choice to use the new directory structure was easy. I have a number of apps and use Symfony on a daily basis. Keeping up with the latest and greatest makes sense for me. Spending the time to port apps (some of them dating back to 2.3) to 4.0 makes my overall maintenance burden easier. The time spent experimenting how to port helped me understand the new functionality. Once I got comfortable with the process it was really just copy/paste/rename exercise for the most part. The hardest was making sure some of the 3rd party dependencies were properly updated.
In your case, it seem like you only have one app and you just want to get it updated and then forget about it for a few years. In that case, keep the old structure and move on. At some point you might need to move to the new structure but waiting a few years won't hurt anything. And hey, I suspect 5.0 will introduce more changes.
The choice is yours.
Symfony Flex is the new way to install and manage Symfony applications. Flex is not a new Symfony version, but a tool that replaces and improves the Symfony Installer and the Symfony Standard Edition.
Symfony Flex automates the most common tasks of Symfony applications, like installing and removing bundles and other Composer dependencies. Symfony Flex works for Symfony 3.3 and higher. Starting from Symfony 4.0, Flex should be used by default, but it is still optional.
Source : https://symfony.com/doc/3.4/setup/flex.html
Can anyone knows a library to authenticate users using Symfony HttpFondation Component?
PS Symfony Security Component is not suitable, as too big.
PPS Project does not using Symfony Framework.
I don't think there is any (at this time).
PPI framework uses some of the Symfony components (also HttpFoundation). See how they solved it. Otherwise you'd probably need to handle it yourself.
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
It seems that Symfony 2 is finally stable (correct me if I'm wrong) and I wish to transfer my projects from 1.4 to 2.0.
I checked google and symfony.com but there is no info about this topic. My guess that the framework got rewritten so deeply that no automatized tool can handle this.
Any ideas or guidelines?
Your guess is right, there is no automated tool that can convert your 1.4 project to 2.0, because the structure of the framework, although still MVC of course, is quite different to the 1.X versions.
You can see some of the key differences in this page of the Symfony2 Cookbook.
Also, bear in mind that Symfony2 requires PHP 5.3.2 or higher.
My advice would be, if your projects are finished and running in Symfony1.4, let them be, they'll be just fine, and start learning Symfony2 ;)
Since they are fundamentally different (PHP4 vs PHP5 based), this could be quite a headache I imagine. I would love to transfer my CI app to Kohana 3, but they only have migration tuts for transferring to Kohana 1.x and 2.x.
No, it'd be virtually impossible to just copy everything over.
You had a better chance with Kohana 2.3.4 as it was derived from CodeIgniter and was similar. Kohana 3 is a total rewrite so it would be like migrating to a new framework.
Have a look at Kohana Docs:
Migration
Although it is not specifically for Kohana 3 but probably you can get the idea from it.
I have migrated a CodeIgniter app over to Kohana 3.x, but things are very different so I wouldn't call it a direct port. About the only things I were able to reuse were views (although I converted them to mustache templates) and the SQL from the models.
There is no reason to switch frameworks for an existing application unless there will be continued work on it and you are familiar with the new framework. Because if you do switch, you will basically be rewriting the application. That said, I chose to do my app because I will be maintaining it for a long time and I am more familiar with Kohana. YMMV