This PR was squashed before being merged into the 2.3 branch (closes#14325).
Discussion
----------
[Routing][DependencyInjection] Support .yaml extension in YAML loaders
| Q | A
| ------------- | ---
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #14319
| License | MIT
| Doc PR | -
YAML [FAQ](http://www.yaml.org/faq.html) states that .yaml file extension should be used whenever possible. I tweaked YamlFileLoader supports() method in Symfony Routing component to accept both .yml and .yaml and added some asserts in tests for that behavior.
This PR replaces #14319 as it was based on 2.7. BTW Is there a way to "rebase" PR branch without redoing all the work?
Commits
-------
dd5a811 [Routing][DependencyInjection] Support .yaml extension in YAML loaders
This PR was squashed before being merged into the 2.3 branch (closes#14231).
Discussion
----------
[DependencyInjection] Show better error when the Yaml component is not installed
| Q | A
| ------------- | ---
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| License | MIT
As the Yaml component is a suggested dependency, if someone try to use the `YamlFileLoader` or the `YamlDumper` without the component will get an ugly message:
```
PHP Fatal error: Class 'Symfony\Component\Yaml\Dumper' not found in xxxx
```
With this PR the error will be an exception with the message: `Unable to dump the container as the Symfony Yaml Component is not installed.` for `YamlDumper` and `Unable to load YAML files service definitions as the Symfony Yaml Component is not installed.'` for `YamlFileLoader`
Commits
-------
870a299 [DependencyInjection] Show better error when the Yaml component is not installed
YamlFileLoader used the resource name as the current directory during import, which can cause a failed import when using a relative path. Using the $path variable output from the locator is consistent with other loaders and fixes the bug.
This PR was merged into the master branch.
Discussion
----------
made some optimization when parsing YAML files
| Q | A
| ------------- | ---
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | n/a
| License | MIT
| Doc PR | n/a
This change makes a small speed optimization when loading a YAML file, but more important, it allows to use local stream wrappers instead of regular files on the filesystem.
Commits
-------
0586c7e made some optimization when parsing YAML files
This PR was merged into the master branch.
Discussion
----------
[2.3] [WIP] Synchronized services...
| Q | A
| ------------- | ---
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #5300, #6756
| License | MIT
| Doc PR | symfony/symfony-docs#2343
Todo:
- [x] update documentation
- [x] find a better name than contagious (synchronized)?
refs #6932, refs #5012
This PR is a proof of concept that tries to find a solution for some problems we have with scopes and services depending on scoped services (mostly the request service in Symfony).
Basically, whenever you want to inject the Request into a service, you have two possibilities:
* put your own service into the request scope (a new service will be created whenever a sub-request is run, and the service is not available outside the request scope);
* set the request service reference as non-strict (your service is always available but the request you have depends on when the service is created the first time).
This PR addresses this issue by allowing to use the second option but you service still always has the right Request service (see below for a longer explanation on how it works).
There is another issue that this PR fixes: edge cases and weird behaviors. There are several bug reports about some weird behaviors, and most of the time, this is related to the sub-requests. That's because the Request is injected into several Symfony objects without being updated correctly when leaving the request scope. Let me explain that: when a listener for instance needs the Request object, it can listen to the `kernel.request` event and store the request somewhere. So, whenever you enter a sub-request, the listener will get the new one. But when the sub-request ends, the listener has no way to know that it needs to reset the request to the master one. In practice, that's not really an issue, but let me show you an example of this issue in practice:
* You have a controller that is called with the English locale;
* The controller (probably via a template) renders a sub-request that uses the French locale;
* After the rendering, and from the controller, you try to generate a URL. Which locale the router will use? Yes, the French locale, which is wrong.
To fix these issues, this PR introduces a new notion in the DIC: synchronized services. When a service is marked as synchronized, all method calls involving this service will be called each time this service is set. When in a scope, methods are also called to restore the previous version of the service when the scope leaves.
If you have a look at the router or the locale listener, you will see that there is now a `setRequest` method that will called whenever the request service changes (because the `Container::set()` method is called or because the service is changed by a scope change).
Commits
-------
17269e1 [DependencyInjection] fixed management of scoped services with an invalid behavior set to null
bb83b3e [HttpKernel] added a safeguard for when a fragment is rendered outside the context of a master request
5d7b835 [FrameworkBundle] added some functional tests
ff9d688 fixed Request management for FragmentHandler
1b98ad3 fixed Request management for LocaleListener
a7b2b7e fixed Request management for RequestListener
0892135 [HttpKernel] ensured that the Request is null when outside of the Request scope
2ffcfb9 [FrameworkBundle] made the Request service synchronized
ec1e7ca [DependencyInjection] added a way to automatically update scoped services
Added the possibility to to use '@@' as an escaping strategy for
parameters that should be treated as strings but start with '@'
(i.e. safe mailer passwords).
A service can now be marked as synchronized; when set, all method calls
involving this service will be called each time this service is set.
When in a scope, methods are also called to restore the previous version of the
service.
Commits
-------
24a0d0a [DependencyInjection] Support Yaml calls without arguments
Discussion
----------
[DependencyInjection] Support Yaml calls without arguments
This replaces existing use of core SPL exceptions with the equivalent classes defined within the component. Although method documentation has been changed, this change should be BC since the component-specific SPL exceptions extend their core counterpart.
This commit purposely omits any changes to the PhpDumper, which throws several core SPL exceptions.
This improves, for example, the exception one would receive if they tried to import a resource from a bundle that doesn't exist.
Previously, the deep "bundle is not activated" exception would be thrown. That has value, however there is no indication of where
the exception is actually occurring.
In this new implementation, we throw an exception that explains exactly which resource, and from which source resource, cannot be
loaded. The deeper exception is still thrown as a nested exception.
Two caveats:
* The `HttpKernel::varToString` method was replicated
* This introduces a new `Exception` class, which allows us to prevent lot's of exceptions from nesting into each other in the case
that some deeply imported resource cannot be imported (each upstream import that fails doesn't add its own exception).
