I already read this cookbook, about non shared service, so my question, can this be used in symfony 2.7 ?
As already said, this feature was introduced in 2.8.
So, in 2.7, you can deal with scopes to have several instances of the same service across your application.
To get the same behavior as shared (a new instance for each service call), use:
your_service:
# ...
scope: prototype
From the cookbook that you linked.
2.8 The shared setting was introduced in Symfony 2.8. Prior to Symfony 2.8, you had to use the prototype scope.
There is a combo with versions just below the main title. Select "2.8 version" and check yourself.
Related
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.
the Symfony2 service SecurityContext is deprecated since version 2.6. In a current project under developpment we frequently use user roles. Therefore, it make senses to
switch immediately to the new security services of 2.6.
On the other hand we use FOSUserBundle in the project as well. As far as I see, the latest version of this bundle is at the level of Symfony 2.3. Since in the dev-environment version 2.6 ist not 100% bc with 2.3 (for example if Xdebug is acivated) the usasge of the new services yields conflicts ...
Our questions:
does someone know whether the FOSUserBundle will be compatible wih 2.6 in the near future?
has someone encountered the same problem and can give hints to handle it?
Best wishes
The problem has been solved.
First of all it turned out that all the Deprecated-errors - which prevented a development in our current envirement/configuration - came from a Symfony 2.7-dev version.
It seems that Symfony 2.6 itself does not have such errors. In this sense the above comments were correct. Thus, for the moment one has to use Symfony 2.6 in order to rewrite the own app such that the usage of security aspects becomes compatible with version 2.6.
From a FOS-developer we got the feedback that there will be an 2.6 compatible update of the user bundle before the release of a stable Symfony 2.7 vesion. Therefor one can switch smoothly form 2.6 to 2.7.
I need to upgrade an existing rather large application from Symfony 2.0.15 to Symfony 2.4.x (replace with current version).
I'm not quite sure what would be the best strategy to do so. Migration critical features like forms or esi are used, of course :)
Upgrade "step by step" from one major version to another (2.1, 2.2, 2.3, 2.4)
Upgrade directly from 2.0.x to 2.4
Do you have any tips / experience to share ? Would appreciate it :)
Thanks,
Stephan
Each new version comes with an update UPGRADE-2.x.md file containing all intructions to convert your application from the immediately previous version.
I had to do that on my project as well, and I found the step-by-step method more natural and easier to manage. Fact is, there is no file such file as UPGRADE-2.0-to-2.4.md that would help you out for a direct conversion to 2.4.
I shall first recommend to make sure that none of your code uses obsolete functionnalities of Symfony 2.0 (not sure if there are deprecated parts in this version, though), because these can be removed in ulterior versions and will not be included in the UPGRADE file.
If you have done indeep modifications of the core Symfony code, you may find that some undocumented modifications are needed. For instance, there is a custom error handler in my project, extending the Symfony error handler. Well, although it was not documented in the UPGRADE file, the signature of ErrorHandler::handle() was modified and needed to be updated in my custom handler.
Similarly, I had to modify some namespaces because files had been moved in the framework code.
The conversion is still ongoing and I'm currently experiencing a weird error I'm trying to get rid of: The 'request' scope on services registered on custom events generates errors in the logs.
I have a previous project running Ninject 2.0 runtime version 2.0 and now I am using Ninject in a new project and using the new Ninject, ninject web.mvc version 2.2 for runtime version 4.0.
Every single time I get the error no parameterless constructor
Invalid Operation exception
An error occurred when trying to create a controller of type HomeController'. Make sure that the controller has a parameterless public constructor.
What am I missing. All the bindings are registered.
Do I need to now define interfaces for Controllers as well such as HomeController as IHomeController as I have seen in some examples, Or do I get back to using the older version
There is one version that does not show activation exceptions properly but show this exception instead. Most likely the problem is a duplicated binding.
In addition to what Remo Gloor said, you might want to check that MVC is set up to use Ninject correctly. I was doing some things manually on an older version of the MVC plugin and ended up needing to just bite the bullet and make Global extend the NinjectHttpApplication class, which I had previously been avoiding.
The error you're getting is the error you would get if MVC tries using its built-in controller factory to produce controllers. So you may want to create a custom method binding on your controller class and put a breakpoint inside to make sure it's even being invoked.
You may also want to switch to version 2.3. You can pick up the latest builds of Ninject and all its extensions here.
I have seen this issue mentioned couple of times on forums where there is no direct answer, here is the solution to the above problem, i.e., working with latest ninject
Download the latest Ninject from github.
The ninject I got for MVC2 is named as Ninject.Web.Mvc2-2.2.0.0-release-net-4.0 (runtime version 4)
Now during adding reference add Ninject.Web.Mvc.dll(check the version is same as above by right click properties in VS)
Now Add Ninject.dll from the lib folder in same parent folder (check the version as above)
Now Add CommonServiceLocator.NinjectAdapter.dll from the extensions folder in lib parent folder (check the version as above.)
The missing link in all these have been the commonserviceLocator.dll and the correct version should match. This should be tried if you are sure your bindings are correct as mine were and check to see if your project work with older version.
Thanks to everyone, and good luck :)
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