Change Pimple with Symfony dependency injection - symfony

Is there a way to swap Pimple with Symfony dependency injection?
I can use Symfony dependency injection as a standalone package with Silex but i need to swap Pimple with it because i can't access controllers registered with Symfony dependency injection from Silex like:
$app->get('/route', 'testController:indexAction');

No you can't. Silex does not allow to change the container as the Silex main class extends from Pimple itself. If you need the Symfony container you should go with Symfony and not with Silex.
You could hack up a solution in which every call to Pimple is forwarded to DIC (Pimple would be a kind of proxy service only), but I wouldn't go that route.
Keep in mind that with the upcoming Symfony 4 (due on November, but there is a preview already aviable) the framework is going to be more like Silex: instead of having it all and remove the parts you don't use, you'll start small and add components/bundles/libraries into your project (check out Symfony flex).
Finally, as a side note/fun fact, there was a project from igorw (one of the coauthors of Silex) which replaced Pimple with Symfony DIC component, but it was more an academic exercise rather than a ready to use framework (it did work)

Related

Why is accesing services by classname good?

I've always worked in Symfony 2.2 and 2.8
Now glancing at the blog of the version 3.3 and I can't overcome the new feature of getting services by (fully qualified) class name:
// before Symfony 3.3
$this->get('app.manager.user')->save($user);
// Symfony 3.3
$this->get(UserManager::class)->save($user);
Before Symfony 3.3 the service container was a factory with the knowledge of how to instantiate the service class, with the great benefit of a factory: You can swith the old class to any other class, and as long as they both let's say implement the same interface, maybe you don't even have to touch anything else in your code. But if you ask for a service by class name, you have to refactor your whole code, and change the class name in every occurrence of the service. Either when directly accessing by $container->get() or by using typehint and autowire.
Considering these the old way service aliasing seem much more practical or am I just missing something? I know you still can use it the old way, I'm just wondering in what cases could one benefit from preferring this new method instead the classic one.
One of the main points about the new style of service naming it to avoid asking for services by name directly from the container. By typehinting them all (and having them instead created by the framework), then any service that is not being used at all (and is private, so not get-able), can be removed. Anything that is hinted via the container and does not exist will immediately fail on the container building step as well - it would not be possible to rename a service and forget to also change all the other uses of it.
With so much being injected into the controllers (or a controller action) as well, unit testing the services, and even controllers is also more controllable - there wouldn't be any other things that are being pulled from the container within a test.
As for the transition, because of the container compilation step, Symfony is very good about being able to say if there is anything wrong, or at least deprecated. It's not hard to mark all the current services as public with just a small Yaml snippet at the top of each services.yml file (or anywhere else they are defined).
It will be a while until most of the 3rd party bundles and other supporting libraries will be fully 4.0 compatible, but it was also the case for the breaking changes between 2.8 & 3.0. This is a large part of the reason why 2.8 & now 3.4 are long-term-supported versions - with 3.4 supported to November 2021, giving plenty of time to upgrade away from the deprecations and update the 3rd party bundles.

Can Symfony Bundle be used in non-Symfony project (f.e. Zend)?

Can I reuse my Bundle created in Symfony in non-Symfony project, f.e. Zend? (Or I only can reuse Components?)
What about services from that Bundle?
A Symfony bundle can certainly be included in with other projects, via a composer.json & composer.lock file - it doesn't mean that there is any useful code to run within that bundle however.
If there is useful code as part of the bundle, then you can use it directly, but a Symfony Bundle is just a library that will usually include some Symfony-specific configuration.
Best practice for a bundle is to put any useful, common code, into a separate library (which could be used independently - such as what Symfony calls a 'Component'), and then enable that code (for example creating Symfony services, or configuration) with the bundle configuration.
There have been projects that are Symfony bundles, and also have the configurations for other frameworks as well, such as Silex, and also appropriate Laravel configurations within the same codebase.

What is the difference between a bundle, component and a service in Symfony Framework?

What is a difference between bundle, component, service in Symfony? Thank you in advance
Bundle: A collection of code and other files written for use in a Symfony application.
http://symfony.com/doc/current/book/bundles.html
Component: Parts of the Framework that handle a certain task. They can also be used without the Framework.
http://symfony.com/doc/current/components/index.html
Service: Just a php class that provides certain functionality. It can be loaded through the Service Container which automatically handles dependencies.
http://symfony.com/doc/current/book/service_container.html
As I understand:
Components - standalone official libraries that can be used ether separately from Symfony framework or as a part of so called "Symfony-framework-skeleton". They are independent from other libraries.
Bundles - libraries that are additional to "core Symfony". They are dependent from Symfony components.
Services - libraries written by usual users for local projects that can be reused in different projects.
Service is any php class that has a relation with the dependency injection container, meaning that the container is able to manage it.
A component is a self contained entity that has usability even outside of a symfony based application, a library like PDO.
A bundle is symfony flex abstraction for providing simple modularity including configurations and automations.
So a bundle can be made out of a component.

Sensiolabs/Symfony duplicated components: Which ones should I use?

Pimple or Container?
http://pimple.sensiolabs.org/
http://components.symfony-project.org/dependency-injection/
Twig or Template?
http://twig.sensiolabs.org/
http://components.symfony-project.org/templating/
I'm not asking for an opinion, I just want to know this:
Why are these components being distributed with different names?
Which ones are newer?
Which are the ones being used by symfony 2 ?
Is there a list for components like Pimple and Twig? Like there is for Container and Template: http://components.symfony-project.org/
There are 3 categories of projects you have listed.
Third-party library. While provided by sensiolabs, these are standalone libraries not under the symfony namespace.
Old Symfony 1.x components, also standalone but under the Symfony namespace. Available at components.symfony-project.org, compatible with PHP 5.2.
Symfony2 components, part of the Symfony2 package, but can also be used standalone. Compatible with PHP 5.3+.
Ok, so let's categorize the projects you've listed.
Category 1
Pimple
Twig
There is currently no Pimple bundle for Symfony2. The recommended way to go with is to use the Symfony2 DependencyInjection component, which ships with the framework.
Note: Pimple is heavily used by Silex, so if you like Pimple, you might want to take a look at it. It's a different framework that is based on Symfony2 components.
Twig, on the other hand, is supported very well by the Symfony2 core framework. There is a core Bundle for it, and most of the documentation suggests you use it. It is definitely the recommended way to do templating in Symfony2.
For a list of more of these, take a look at Fabien Potencier's GitHub profile. IMO the important ones are: Twig, Silex, Pimple, Goutte, (Pirum, Sismo).
Category 2
Symfony Components DependencyInjection
Symfony Components Templating
These are old and should no longer be used.
Category 3
Symfony2 DependencyInjection Component
Symfony2 Templating Component
Symfony2 Twig Bundle
These are all part of the Symfony2 framework, and you should use them. They are the latest and greatest.
Hope that answers your questions!
I think that you could use http://components.symfony-project.org components if you have some kind of legacy project that uses php 5.2 or your server has php older than 5.3.
I have a project, I' m doing some rewriting, but it's legacy php 5.2 so I decited to use the old components (http://components.symfony-project.org) instead of new symfony's 2.0 components

what is the "core" of symfony2?

the core seems to be everything beneath /vendor/symfony/src/Symfony.
There you have three folders:
/Bridge
/Bundle
/Component
What is the purpose of /Bridge and /Bundle?
Also am I right that core means actually two things?
the core library in /Component
the whole setup with caching of routes/config/templates, admin interface, ...
Symfony2 framework is made of: Components, Bridges, and Bundles.
A Component is a standalone library which can be used independently.
A Bridge is a set of classes from one component that extends another library/component. It has been created so components can stay as decoupled as possible. This is also here for a good reason: If you want to use the Form component but do not use Doctrine as an ORM, you don't care about the specific Type created for Doctrine.
A Bundle is a glue between components or Third-Party libraries. The glue of all these components and bridges that make the Symfony2 framework is the FrameworkBundle.
Then, you have the distributions. A distribution is a set of Bundles, third-party libraries and default configurations that makes the installation of Symfony2 really easy for a project.

Resources