This repository has been archived on 2023-08-20. You can view files and clone it, but cannot push or open issues or pull requests.
symfony/src/Symfony/Component/DependencyInjection/CHANGELOG.md

218 lines
9.4 KiB
Markdown
Raw Normal View History

2012-04-26 21:08:35 +01:00
CHANGELOG
=========
2018-10-25 08:05:21 +01:00
4.3.0
-----
2019-01-04 17:50:27 +00:00
* added `%env(trim:...)%` processor to trim a string value
* added `%env(default:param_name:...)%` processor to fallback to a parameter or to null when using `%env(default::...)%`
2018-10-25 07:43:38 +01:00
* added `%env(url:...)%` processor to convert an URL or DNS into an array of components
* added `%env(query_string:...)%` processor to convert a query string into an array of key values
* added support for deprecating aliases
2019-01-31 12:39:06 +00:00
* made `ContainerParametersResource` final and not implement `Serializable` anymore
* added `ReverseContainer`: a container that turns services back to their ids
* added ability to define an index for a tagged collection
* added ability to define an index for services in an injected service locator argument
2018-10-25 08:05:21 +01:00
4.2.0
-----
* added `ContainerBuilder::registerAliasForArgument()` to support autowiring by type+name
* added support for binding by type+name
* added `ServiceSubscriberTrait` to ease implementing `ServiceSubscriberInterface` using methods' return types
* added `ServiceLocatorArgument` and `!service_locator` config tag for creating optimized service-locators
* added support for autoconfiguring bindings
* added `%env(key:...)%` processor to fetch a specific key from an array
2018-08-16 09:54:12 +01:00
* deprecated `ServiceSubscriberInterface`, use the same interface from the `Symfony\Contracts\Service` namespace instead
* deprecated `ResettableContainerInterface`, use `Symfony\Contracts\Service\ResetInterface` instead
2017-12-01 14:34:03 +00:00
4.1.0
-----
* added support for variadics in named arguments
* added PSR-11 `ContainerBagInterface` and its `ContainerBag` implementation to access parameters as-a-service
* added support for service's decorators autowiring
* deprecated the `TypedReference::canBeAutoregistered()` and `TypedReference::getRequiringClass()` methods
2018-03-03 10:07:55 +00:00
* environment variables are validated when used in extension configuration
* deprecated support for auto-discovered extension configuration class which does not implement `ConfigurationInterface`
2017-12-01 14:34:03 +00:00
2017-05-18 20:41:19 +01:00
4.0.0
-----
2017-09-28 17:40:37 +01:00
* Relying on service auto-registration while autowiring is not supported anymore.
Explicitly inject your dependencies or create services whose ids are
their fully-qualified class name.
Before:
```php
namespace App\Controller;
use App\Mailer;
class DefaultController
{
public function __construct(Mailer $mailer) {
// ...
}
// ...
}
```
```yml
services:
App\Controller\DefaultController:
autowire: true
```
After:
```php
// same PHP code
```
```yml
services:
App\Controller\DefaultController:
autowire: true
# or
# App\Controller\DefaultController:
# arguments: { $mailer: "@App\Mailer" }
App\Mailer:
autowire: true
```
* removed autowiring services based on the types they implement
* added a third `$methodName` argument to the `getProxyFactoryCode()` method
of the `DumperInterface`
* removed support for autowiring types
2017-05-18 20:41:19 +01:00
* removed `Container::isFrozen`
* removed support for dumping an ucompiled container in `PhpDumper`
* removed support for generating a dumped `Container` without populating the method map
* removed support for case insensitive service identifiers
* removed the `DefinitionDecorator` class, replaced by `ChildDefinition`
* removed the `AutowireServiceResource` class and related `AutowirePass::createResourceForClass()` method
* removed `LoggingFormatter`, `Compiler::getLoggingFormatter()` and `addLogMessage()` class and methods, use the `ContainerBuilder::log()` method instead
* removed `FactoryReturnTypePass`
* removed `ContainerBuilder::addClassResource()`, use the `addObjectResource()` or the `getReflectionClass()` method instead.
* removed support for top-level anonymous services
* removed silent behavior for unused attributes and elements
* removed support for setting and accessing private services in `Container`
* removed support for setting pre-defined services in `Container`
* removed support for case insensitivity of parameter names
2017-10-02 12:43:47 +01:00
* removed `AutowireExceptionPass` and `AutowirePass::getAutowiringExceptions()`, use `Definition::addError()` and the `DefinitionErrorExceptionPass` instead
2017-05-18 20:41:19 +01:00
3.4.0
-----
* moved the `ExtensionCompilerPass` to before-optimization passes with priority -1000
* deprecated "public-by-default" definitions and aliases, the new default will be "private" in 4.0
2016-10-22 17:25:15 +01:00
* added `EnvVarProcessorInterface` and corresponding "container.env_var_processor" tag for processing env vars
* added support for ignore-on-uninitialized references
* deprecated service auto-registration while autowiring
* deprecated the ability to check for the initialization of a private service with the `Container::initialized()` method
2017-05-25 07:46:02 +01:00
* deprecated support for top-level anonymous services in XML
2017-08-12 10:16:19 +01:00
* deprecated case insensitivity of parameter names
* deprecated the `ResolveDefinitionTemplatesPass` class in favor of `ResolveChildDefinitionsPass`
* added `TaggedIteratorArgument` with YAML (`!tagged foo`) and XML (`<service type="tagged"/>`) support
* deprecated `AutowireExceptionPass` and `AutowirePass::getAutowiringExceptions()`, use `Definition::addError()` and the `DefinitionErrorExceptionPass` instead
3.3.0
-----
* deprecated autowiring services based on the types they implement;
rename (or alias) your services to their FQCN id to make them autowirable
* added "ServiceSubscriberInterface" - to allow for per-class explicit service-locator definitions
* added "container.service_locator" tag for defining service-locator services
* added anonymous services support in YAML configuration files using the `!service` tag.
* added "TypedReference" and "ServiceClosureArgument" for creating service-locator services
* added `ServiceLocator` - a PSR-11 container holding a set of services to be lazily loaded
* added "instanceof" section for local interface-defined configs
* added prototype services for PSR4-based discovery and registration
* added `ContainerBuilder::getReflectionClass()` for retrieving and tracking reflection class info
* deprecated `ContainerBuilder::getClassResource()`, use `ContainerBuilder::getReflectionClass()` or `ContainerBuilder::addObjectResource()` instead
* added `ContainerBuilder::fileExists()` for checking and tracking file or directory existence
* deprecated autowiring-types, use aliases instead
* added support for omitting the factory class name in a service definition if the definition class is set
* deprecated case insensitivity of service identifiers
* added "iterator" argument type for lazy iteration over a set of values and services
* added file-wide configurable defaults for service attributes "public", "tags",
"autowire" and "autoconfigure"
* made the "class" attribute optional, using the "id" as fallback
* using the `PhpDumper` with an uncompiled `ContainerBuilder` is deprecated and
will not be supported anymore in 4.0
* deprecated the `DefinitionDecorator` class in favor of `ChildDefinition`
2017-01-17 13:46:23 +00:00
* allow config files to be loaded using a glob pattern
2017-05-24 16:30:25 +01:00
* [BC BREAK] the `NullDumper` class is now final
3.2.0
-----
* allowed to prioritize compiler passes by introducing a third argument to `PassConfig::addPass()`, to `Compiler::addPass` and to `ContainerBuilder::addCompilerPass()`
* added support for PHP constants in YAML configuration files
* deprecated the ability to set or unset a private service with the `Container::set()` method
* deprecated the ability to check for the existence of a private service with the `Container::has()` method
* deprecated the ability to request a private service with the `Container::get()` method
* deprecated support for generating a dumped `Container` without populating the method map
2015-09-04 20:54:37 +01:00
3.0.0
-----
* removed all deprecated codes from 2.x versions
2015-05-20 02:15:13 +01:00
2.8.0
-----
* deprecated the abstract ContainerAware class in favor of ContainerAwareTrait
2015-09-04 21:16:19 +01:00
* deprecated IntrospectableContainerInterface, to be merged with ContainerInterface in 3.0
2015-05-20 02:15:13 +01:00
* allowed specifying a directory to recursively load all configuration files it contains
* deprecated the concept of scopes
* added `Definition::setShared()` and `Definition::isShared()`
* added ResettableContainerInterface to be able to reset the container to release memory on shutdown
* added a way to define the priority of service decoration
2016-03-21 07:27:21 +00:00
* added support for service autowiring
2015-05-20 02:15:13 +01:00
2.7.0
-----
* deprecated synchronized services
2.6.0
-----
* added new factory syntax and deprecated the old one
2.5.0
-----
* added DecoratorServicePass and a way to override a service definition (Definition::setDecoratedService())
* deprecated SimpleXMLElement class.
2013-07-13 23:01:02 +01:00
2.4.0
-----
* added support for expressions in service definitions
2013-07-13 23:01:02 +01:00
* added ContainerAwareTrait to add default container aware behavior to a class
2012-12-06 12:09:44 +00:00
2.2.0
-----
* added Extension::isConfigEnabled() to ease working with enableable configurations
2012-12-06 12:09:44 +00:00
* added an Extension base class with sensible defaults to be used in conjunction
merged branch lsmith77/pre_process_app_config (PR #5566) This PR was merged into the master branch. Commits ------- d7a1154 make it possible for bundles extensions to prepend settings into the application configuration of any Bundle Discussion ---------- [2.2] add possibility for bundles extensions to prepend the app configs Bug fix: #4652 Feature addition: yes Backwards compatibility break: no Symfony2 tests pass: yes License of the code: MIT As can be seen in the patch the extensions that should prepend the configuration are enabled automatically if they implement ``PrependExtensionInterface``. Just as an example, here an extension, which checks if SonataAdminBundle is available and if not disables integration with it in several Bundles. It also sets some default settings for ``document_class`` and ``default_document_manager_name``: ``` diff --git a/DependencyInjection/SymfonyCmfCoreExtension.php b/DependencyInjection/SymfonyCmfCoreExtension.php index 9f92410..c0a8dbb 100644 --- a/DependencyInjection/SymfonyCmfCoreExtension.php +++ b/DependencyInjection/SymfonyCmfCoreExtension.php @@ -3,11 +3,12 @@ namespace Symfony\Cmf\Bundle\CoreBundle\DependencyInjection; use Symfony\Component\HttpKernel\DependencyInjection\Extension; +use Symfony\Component\\DependencyInjection\PrependExtensionInterface; use Symfony\Component\DependencyInjection\ContainerBuilder; use Symfony\Component\DependencyInjection\Loader\XmlFileLoader; use Symfony\Component\Config\FileLocator; -class SymfonyCmfCoreExtension extends Extension +class SymfonyCmfCoreExtension extends Extension implements PrependExtensionInterface { public function load(array $configs, ContainerBuilder $container) { @@ -15,4 +16,45 @@ class SymfonyCmfCoreExtension extends Extension $loader->load('config.xml'); $loader->load('services.xml'); } + + public function prepend(ContainerBuilder $container) + { + $bundles = $container->getParameter('kernel.bundles'); + if (!isset($bundles['SonataDoctrinePHPCRAdminBundle'])) { + // disable SonataDoctrinePHPCRAdminBundle admin support in Bundles + $config = array('use_sonata_admin' => false); + foreach ($container->getExtensions() as $name => $extension) { + switch ($name) { + case 'symfony_cmf_menu': + case 'symfony_cmf_routing_extra': + case 'symfony_cmf_simple_cms': + $container->prependExtensionConfig($name, $config); + break; + } + } + } + + // process the configuration of SymfonyCmfCoreExtension + $configs = $container->getExtensionConfig($this->getAlias()); + $config = $this->processConfiguration(new Configuration(), $configs); + // add the default configs to various Bundles + foreach ($container->getExtensions() as $name => $extension) { + switch ($name) { + case 'symfony_cmf_content': + case 'symfony_cmf_simple_cms': + $container->prependExtensionConfig($name, $config); + break; + } + } + } } ``` --------------------------------------------------------------------------- by stof at 2012-09-21T21:10:00Z I think you are giving too much power to bundles here: a bundle becomes able to modify all the config defined explicitly by the user if it wants to do it. I think it would be safer to give them the possibility to load an additional config file which would be prepended (so that user-defined config would still win). Giving the ability to load files means passing the loader used by the kernel, and it should then be called before calling the load method on the kernel itself (to respect the order of loaded files) --------------------------------------------------------------------------- by lsmith77 at 2012-09-22T05:50:08Z Not sure how a config file helps solve anything. I mean they can load as many config files as they want already. The key is being able to automatically apply configuration to multiple Bundles as well as enabling/disabling features based on if certain Bundles are registered. BTW the end result in my examples is also prepended, so that user config wins. However yes this would be up to the person implementing the Bundle. We could however provide a dedicated method for prepending in addition to or instead of ``setExtensionConfig``. --------------------------------------------------------------------------- by stof at 2012-09-22T11:40:29Z @lsmith77 If you can load a file with the main loader, this file can provide some app-level configuration (be it for your own bundle or others). And your code example is indeed prepending. But imagine what would occur when someone uses this feature without knowing well how the component works: he will likely call ``setExtensionConfig`` in a first implementation, thus dropping all userland config for the bundle. Your setup does not only allow to make a file win over the userland config but makes it even easier to remove the userland config. --------------------------------------------------------------------------- by lsmith77 at 2012-09-22T18:11:29Z but i dont get how that would help. the point is to be able for one bundle to configure other bundles before the load as this is obviously alot cleaner than trying to do the same via a compiler pass. so imho this is what is needed to encourage decoupled bundles. otherwise for example CMS or other reuseable and extensible apps will be forced to always put everything in one bundle. --------------------------------------------------------------------------- by stof at 2012-09-22T19:23:45Z @lsmith77 I agree about the feature, not about the way to implement it. If you allow bundles to load a file as it it were some app-level config, they would become able to provide some config for other bundles (and you could load several files depending of which bundles are enabled), but without allowing bundles to remove the userland config. --------------------------------------------------------------------------- by lsmith77 at 2012-09-22T19:50:19Z sorry but i dont understand what you suggest. more over i dont see the problem. its already possible to seriously break stuff with compiler passes which cannot be easily enabled/disabled. this is just convenience. if it doesnt work because of some obscure combo then simply dont use it for the app since it needs to be explicitly enabled in the kernel. --------------------------------------------------------------------------- by lsmith77 at 2012-09-24T09:25:10Z @stof thought about your comments, are you suggesting for a Bundle to be able to generate a config file that is prepended? in that case the current behavior would already be that if we change ``setExtensionConfig`` to just be a ``prependExtensionConfig`` .. however i am not sure if we really need this limitation since as i point out this would still by far be less dangerous than compiler passes and also i expect this to be used mainly by open source applications on top of Symfony2 rather than standard bundles. --------------------------------------------------------------------------- by lsmith77 at 2012-10-13T13:28:29Z @lolautruche i also think this is relevant for you guys. this way you could start preconfiguring 3rd party bundles as part of your main ezPublish bundle. --------------------------------------------------------------------------- by lolautruche at 2012-10-13T13:57:09Z While I suspect a nice feature, the implementation looks obscure to me... --------------------------------------------------------------------------- by lsmith77 at 2012-10-13T17:43:02Z The implementation of the example extension or the implementation of the actual changes proposed in this PR? --------------------------------------------------------------------------- by lolautruche at 2012-10-13T17:46:57Z The example, sorry :smiley: --------------------------------------------------------------------------- by lsmith77 at 2012-10-13T17:50:38Z The example was fairly quickly hacked together. The basic thing you need to do is fetch the config for the bundle you want to change, manipulate the config (usually by appending an array to the array of configs so that you dont affect explicit configuration) and then set it again. As I explained to @stof it would alternative/additionally be possible to support a method that pushes a config array to the top of the array of config stack. Such a method might make the necessary code simpler. --------------------------------------------------------------------------- by stof at 2012-10-13T21:39:07Z @fabpot what do you think about it ? --------------------------------------------------------------------------- by jrobeson at 2012-10-20T15:45:18Z I've been porting much of an existing framework over to use more symfony components and bundles. I think that this might help some of the problems i've been having. I would really appreciate some better examples as how to one would use it (same for the cmf router, but that's another story). --------------------------------------------------------------------------- by lsmith77 at 2012-10-21T07:28:52Z not really sure what other examples i could give. the process is quite simple: 1) determine what configuration options to add to other Bundles for example with the following code I determine that SonataAdmin for PHPCR is not installed (which means i should disable using it in other Bundles): ``` $bundles = $container->getParameter('kernel.bundles'); if (!isset($bundles['SonataDoctrinePHPCRAdminBundle'])) { ``` alternatively I could simply already process the configuration and then pick all or some of these configuration options: ``` $configs = $container->getExtensionConfig($this->getAlias()); $config = $this->processConfiguration(new Configuration(), $configs); ``` 2) then add these configuration to what other Bundles I feel should get these options usually I will add these to the top of the config array stack. this means that if the user would manually set the same setting in most cases the user setting will override what the pre-processor set. ``` $container->unshiftExtensionConfig($name, array('use_sonata_admin' => false)); ``` --------------------------------------------------------------------------- by lsmith77 at 2012-10-24T12:52:38Z added ``ContainerBuilder::unshiftExtensionConfig`` since this is the usual use case. with this method added it could be discussed if ``ContainerBuilder::setExtensionConfig`` is still needed or not. --------------------------------------------------------------------------- by lsmith77 at 2012-11-24T14:48:44Z I spoke to @fabpot today and he said that since this patch just allows you to set defaults and not really "process" the actual configuration I shouldn't call it "preProcess" so I renamed it to "prepend". Furthermore as its just prepending @fabpot said there isnt really a need to require manually enabling it, so here is a patch to auto-enable the prepending logic: ``` diff --git a/src/Symfony/Component/HttpKernel/Kernel.php b/src/Symfony/Component/HttpKernel/Kernel.php index b890fbf..7374b87 100644 --- a/src/Symfony/Component/HttpKernel/Kernel.php +++ b/src/Symfony/Component/HttpKernel/Kernel.php @@ -701,8 +701,8 @@ abstract class Kernel implements KernelInterface, TerminableInterface */ protected function prependExtensionConfigs(ContainerBuilder $container) { - foreach ($this->getPrependingExtensions() as $name) { - $extension = $container->getExtension($name); + foreach ($this->bundles as $bundle) { + $extension = $bundle->getContainerExtension(); if ($extension instanceof PrependExtensionInterface) { $extension->prepend($container); } @@ -710,16 +710,6 @@ abstract class Kernel implements KernelInterface, TerminableInterface } /** - * Returns the ordered list of extensions that may prepend extension configurations. - * - * @return array - */ - protected function getPrependingExtensions() - { - return array(); - } - - /** * Gets a new ContainerBuilder instance used to build the service container. * * @return ContainerBuilder ``` --------------------------------------------------------------------------- by lsmith77 at 2012-11-25T19:31:01Z ok .. i pondered the code some more and now i have enabled registering of the prepending extensions by default, since its now quite easy to just override the ``prependExtensionConfigs()`` method since there is almost no logic in there anymore. @fabpot i am not 100% sure with the naming yet .. --------------------------------------------------------------------------- by lsmith77 at 2012-12-05T14:03:43Z @fabpot if you are ok with the PR as it is now, i can do the rebase so you can merge this? --------------------------------------------------------------------------- by lsmith77 at 2012-12-05T18:30:29Z @fabpot all good now? then i will squash the commits .. --------------------------------------------------------------------------- by lsmith77 at 2012-12-05T18:34:50Z actually looking at the full change set again i am no longer sure if it makes sense to have ``PrependExtensionInterface`` in the DI rather than the HttpKernel. --------------------------------------------------------------------------- by lsmith77 at 2012-12-07T09:21:14Z @fabpot all good now? --------------------------------------------------------------------------- by fabpot at 2012-12-07T09:37:52Z The code looks good to me now. There are two remaining task before merging: * Is it something we need to add somewhere in the documentation? * Can you add a note in the DI component CHANGELOG? Thanks. --------------------------------------------------------------------------- by lsmith77 at 2012-12-07T09:49:17Z i have added a changelog entry and squashed the commits. i will also work on a documentation entry, i guess i will make it a cookbook entry. not sure if it should be included in http://symfony.com/doc/2.0/cookbook/bundles/extension.html .. but imho it would better be a separate entry.
2012-12-07 10:04:59 +00:00
with the Config component.
* added PrependExtensionInterface (to be able to allow extensions to prepend
application configuration settings for any Bundle)
2012-12-06 12:09:44 +00:00
2012-04-26 21:08:35 +01:00
2.1.0
-----
* added IntrospectableContainerInterface (to be able to check if a service
has been initialized or not)
* added ConfigurationExtensionInterface
* added Definition::clearTag()
* component exceptions that inherit base SPL classes are now used exclusively
(this includes dumped containers)
* [BC BREAK] fixed unescaping of class arguments, method
ParameterBag::unescapeValue() was made public