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/Config/Definition/ArrayNode.php

401 lines
11 KiB
PHP
Raw Normal View History

<?php
/*
* This file is part of the Symfony package.
*
* (c) Fabien Potencier <fabien@symfony.com>
*
* For the full copyright and license information, please view the LICENSE
* file that was distributed with this source code.
*/
namespace Symfony\Component\Config\Definition;
use Symfony\Component\Config\Definition\Exception\InvalidConfigurationException;
use Symfony\Component\Config\Definition\Exception\InvalidTypeException;
use Symfony\Component\Config\Definition\Exception\UnsetKeyException;
[Security/DependencyInjection] adds support for merging security configurations The merging is done in three steps: 1. Normalization: ================= All passed config arrays will be transformed into the same structure regardless of what format they come from. 2. Merging: =========== This is the step when the actual merging is performed. Starting at the root the configs will be passed along the tree until a node has no children, or the merging of sub-paths of the current node has been specifically disabled. Left-Side Right-Side Merge Result ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -nothing- array Right-Side will be taken. scalar scalar Right-Side will be taken. array false Right-Side will be taken if ->canBeUnset() was called on the array node. false array Right-Side will be taken. array array Each value in the array will be passed to the specific child node, or the prototype node (whatever is present). 3. Finalization: ================ The normalized, and merged config will be passed through the config tree to perform final validation on the submitted values, and set default values where this has been requested. You can influence this process in various ways, here is a list with some examples. All of these methods must be called on the node on which they should be applied. * isRequired(): Node must be present in at least one config file. * requiresAtLeastOneElement(): PrototypeNode must have at least one element. * treatNullLike($value): Replaces null with $value during normalization. * treatTrueLike($value): Same as above just for true * treatFalseLike($value): Same as above just for false * defaultValue($value): Sets a default value for this node (only for scalars) * addDefaultsIfNotSet(): Whether to add default values of an array which has not been defined in any configuration file. * disallowNewKeysInSubsequentConfigs(): All keys for this array must be defined in one configuration file, subsequent configurations may only overwrite these. * fixXmlConfig($key, $plural = null): Transforms XML config into same structure as YAML, and PHP configurations. * useAttributeAsKey($name): Defines which XML attribute to use as array key. * cannotBeOverwritten(): Declares a certain sub-path as non-overwritable. All configuration for this path must be defined in the same configuration file. * cannotBeEmpty(): If value is set, it must be non-empty. * canBeUnset(): If array values should be unset if false is specified. Architecture: ============= The configuration consists basically out of two different sets of classes. 1. Builder classes: These classes provide the fluent interface and are used to construct the config tree. 2. Node classes: These classes contain the actual logic for normalization, merging, and finalizing configurations. After you have added all the metadata to your builders, the call to ->buildTree() will convert this metadata to actual node classes. Most of the time, you will not have to interact with the config nodes directly, but will delegate this to the Processor class which will call the respective methods on the config node classes.
2011-02-04 13:37:01 +00:00
/**
[Config] Component refactoring The Config component API have changed and the extension configuration files must be updated accordingly: 1. Array nodes must enclosed their children definition in ->children() ... ->end() calls: Before: $treeBuilder->root('zend', 'array') ->arrayNode('logger') ->scalarNode('priority')->defaultValue('INFO')->end() ->booleanNode('log_errors')->defaultFalse()->end() ->end(); After: $treeBuilder->root('zend', 'array') ->children() ->arrayNode('logger') ->children() ->scalarNode('priority')->defaultValue('INFO')->end() ->booleanNode('log_errors')->defaultFalse()->end() ->end() ->end() ->end(); 2. The 'builder' method (in NodeBuilder) has been dropped in favor of an 'append' method (in ArrayNodeDefinition) Before: $treeBuilder->root('doctrine', 'array') ->arrayNode('dbal') ->builder($this->getDbalConnectionsNode()) ->end(); After: $treeBuilder->root('doctrine', 'array') ->children() ->arrayNode('dbal') ->append($this->getDbalConnectionsNode()) ->end() ->end(); 3. The root of a TreeBuilder is now an NodeDefinition (and most probably an ArrayNodeDefinition): Before: $root = $treeBuilder->root('doctrine', 'array'); $this->addDbalSection($root); public function addDbalSection(NodeBuilder $node) { ... } After: $root = $treeBuilder->root('doctrine', 'array'); $this->addDbalSection($root); public function addDbalSection(ArrayNodeDefinition $node) { ... } 4. The NodeBuilder API has changed (this is seldom used): Before: $node = new NodeBuilder('connections', 'array'); After: The recommended way is to use a tree builder: $treeBuilder = new TreeBuilder(); $node = $treeBuilder->root('connections', 'array'); An other way would be: $builder = new NodeBuilder(); $node = $builder->node('connections', 'array'); Some notes: - Tree root nodes should most always be array nodes, so this as been made the default: $treeBuilder->root('doctrine', 'array') is equivalent to $treeBuilder->root('doctrine') - There could be more than one ->children() ... ->end() sections. This could help with the readability: $treeBuilder->root('doctrine') ->children() ->scalarNode('default_connection')->end() ->end() ->fixXmlConfig('type') ->children() ->arrayNode('types') .... ->end() ->end()
2011-03-14 17:29:56 +00:00
* Represents an Array node in the config tree.
[Security/DependencyInjection] adds support for merging security configurations The merging is done in three steps: 1. Normalization: ================= All passed config arrays will be transformed into the same structure regardless of what format they come from. 2. Merging: =========== This is the step when the actual merging is performed. Starting at the root the configs will be passed along the tree until a node has no children, or the merging of sub-paths of the current node has been specifically disabled. Left-Side Right-Side Merge Result ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -nothing- array Right-Side will be taken. scalar scalar Right-Side will be taken. array false Right-Side will be taken if ->canBeUnset() was called on the array node. false array Right-Side will be taken. array array Each value in the array will be passed to the specific child node, or the prototype node (whatever is present). 3. Finalization: ================ The normalized, and merged config will be passed through the config tree to perform final validation on the submitted values, and set default values where this has been requested. You can influence this process in various ways, here is a list with some examples. All of these methods must be called on the node on which they should be applied. * isRequired(): Node must be present in at least one config file. * requiresAtLeastOneElement(): PrototypeNode must have at least one element. * treatNullLike($value): Replaces null with $value during normalization. * treatTrueLike($value): Same as above just for true * treatFalseLike($value): Same as above just for false * defaultValue($value): Sets a default value for this node (only for scalars) * addDefaultsIfNotSet(): Whether to add default values of an array which has not been defined in any configuration file. * disallowNewKeysInSubsequentConfigs(): All keys for this array must be defined in one configuration file, subsequent configurations may only overwrite these. * fixXmlConfig($key, $plural = null): Transforms XML config into same structure as YAML, and PHP configurations. * useAttributeAsKey($name): Defines which XML attribute to use as array key. * cannotBeOverwritten(): Declares a certain sub-path as non-overwritable. All configuration for this path must be defined in the same configuration file. * cannotBeEmpty(): If value is set, it must be non-empty. * canBeUnset(): If array values should be unset if false is specified. Architecture: ============= The configuration consists basically out of two different sets of classes. 1. Builder classes: These classes provide the fluent interface and are used to construct the config tree. 2. Node classes: These classes contain the actual logic for normalization, merging, and finalizing configurations. After you have added all the metadata to your builders, the call to ->buildTree() will convert this metadata to actual node classes. Most of the time, you will not have to interact with the config nodes directly, but will delegate this to the Processor class which will call the respective methods on the config node classes.
2011-02-04 13:37:01 +00:00
*
* @author Johannes M. Schmitt <schmittjoh@gmail.com>
*/
class ArrayNode extends BaseNode implements PrototypeNodeInterface
{
[Security/DependencyInjection] adds support for merging security configurations The merging is done in three steps: 1. Normalization: ================= All passed config arrays will be transformed into the same structure regardless of what format they come from. 2. Merging: =========== This is the step when the actual merging is performed. Starting at the root the configs will be passed along the tree until a node has no children, or the merging of sub-paths of the current node has been specifically disabled. Left-Side Right-Side Merge Result ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -nothing- array Right-Side will be taken. scalar scalar Right-Side will be taken. array false Right-Side will be taken if ->canBeUnset() was called on the array node. false array Right-Side will be taken. array array Each value in the array will be passed to the specific child node, or the prototype node (whatever is present). 3. Finalization: ================ The normalized, and merged config will be passed through the config tree to perform final validation on the submitted values, and set default values where this has been requested. You can influence this process in various ways, here is a list with some examples. All of these methods must be called on the node on which they should be applied. * isRequired(): Node must be present in at least one config file. * requiresAtLeastOneElement(): PrototypeNode must have at least one element. * treatNullLike($value): Replaces null with $value during normalization. * treatTrueLike($value): Same as above just for true * treatFalseLike($value): Same as above just for false * defaultValue($value): Sets a default value for this node (only for scalars) * addDefaultsIfNotSet(): Whether to add default values of an array which has not been defined in any configuration file. * disallowNewKeysInSubsequentConfigs(): All keys for this array must be defined in one configuration file, subsequent configurations may only overwrite these. * fixXmlConfig($key, $plural = null): Transforms XML config into same structure as YAML, and PHP configurations. * useAttributeAsKey($name): Defines which XML attribute to use as array key. * cannotBeOverwritten(): Declares a certain sub-path as non-overwritable. All configuration for this path must be defined in the same configuration file. * cannotBeEmpty(): If value is set, it must be non-empty. * canBeUnset(): If array values should be unset if false is specified. Architecture: ============= The configuration consists basically out of two different sets of classes. 1. Builder classes: These classes provide the fluent interface and are used to construct the config tree. 2. Node classes: These classes contain the actual logic for normalization, merging, and finalizing configurations. After you have added all the metadata to your builders, the call to ->buildTree() will convert this metadata to actual node classes. Most of the time, you will not have to interact with the config nodes directly, but will delegate this to the Processor class which will call the respective methods on the config node classes.
2011-02-04 13:37:01 +00:00
protected $xmlRemappings;
protected $children;
[Security/DependencyInjection] adds support for merging security configurations The merging is done in three steps: 1. Normalization: ================= All passed config arrays will be transformed into the same structure regardless of what format they come from. 2. Merging: =========== This is the step when the actual merging is performed. Starting at the root the configs will be passed along the tree until a node has no children, or the merging of sub-paths of the current node has been specifically disabled. Left-Side Right-Side Merge Result ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -nothing- array Right-Side will be taken. scalar scalar Right-Side will be taken. array false Right-Side will be taken if ->canBeUnset() was called on the array node. false array Right-Side will be taken. array array Each value in the array will be passed to the specific child node, or the prototype node (whatever is present). 3. Finalization: ================ The normalized, and merged config will be passed through the config tree to perform final validation on the submitted values, and set default values where this has been requested. You can influence this process in various ways, here is a list with some examples. All of these methods must be called on the node on which they should be applied. * isRequired(): Node must be present in at least one config file. * requiresAtLeastOneElement(): PrototypeNode must have at least one element. * treatNullLike($value): Replaces null with $value during normalization. * treatTrueLike($value): Same as above just for true * treatFalseLike($value): Same as above just for false * defaultValue($value): Sets a default value for this node (only for scalars) * addDefaultsIfNotSet(): Whether to add default values of an array which has not been defined in any configuration file. * disallowNewKeysInSubsequentConfigs(): All keys for this array must be defined in one configuration file, subsequent configurations may only overwrite these. * fixXmlConfig($key, $plural = null): Transforms XML config into same structure as YAML, and PHP configurations. * useAttributeAsKey($name): Defines which XML attribute to use as array key. * cannotBeOverwritten(): Declares a certain sub-path as non-overwritable. All configuration for this path must be defined in the same configuration file. * cannotBeEmpty(): If value is set, it must be non-empty. * canBeUnset(): If array values should be unset if false is specified. Architecture: ============= The configuration consists basically out of two different sets of classes. 1. Builder classes: These classes provide the fluent interface and are used to construct the config tree. 2. Node classes: These classes contain the actual logic for normalization, merging, and finalizing configurations. After you have added all the metadata to your builders, the call to ->buildTree() will convert this metadata to actual node classes. Most of the time, you will not have to interact with the config nodes directly, but will delegate this to the Processor class which will call the respective methods on the config node classes.
2011-02-04 13:37:01 +00:00
protected $allowFalse;
protected $allowNewKeys;
protected $addIfNotSet;
protected $performDeepMerging;
protected $ignoreExtraKeys;
protected $normalizeKeys;
2011-02-13 18:06:41 +00:00
/**
* Constructor.
*
2012-05-15 21:19:31 +01:00
* @param string $name The Node's name
2011-02-13 18:06:41 +00:00
* @param NodeInterface $parent The node parent
*/
[Security/DependencyInjection] adds support for merging security configurations The merging is done in three steps: 1. Normalization: ================= All passed config arrays will be transformed into the same structure regardless of what format they come from. 2. Merging: =========== This is the step when the actual merging is performed. Starting at the root the configs will be passed along the tree until a node has no children, or the merging of sub-paths of the current node has been specifically disabled. Left-Side Right-Side Merge Result ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -nothing- array Right-Side will be taken. scalar scalar Right-Side will be taken. array false Right-Side will be taken if ->canBeUnset() was called on the array node. false array Right-Side will be taken. array array Each value in the array will be passed to the specific child node, or the prototype node (whatever is present). 3. Finalization: ================ The normalized, and merged config will be passed through the config tree to perform final validation on the submitted values, and set default values where this has been requested. You can influence this process in various ways, here is a list with some examples. All of these methods must be called on the node on which they should be applied. * isRequired(): Node must be present in at least one config file. * requiresAtLeastOneElement(): PrototypeNode must have at least one element. * treatNullLike($value): Replaces null with $value during normalization. * treatTrueLike($value): Same as above just for true * treatFalseLike($value): Same as above just for false * defaultValue($value): Sets a default value for this node (only for scalars) * addDefaultsIfNotSet(): Whether to add default values of an array which has not been defined in any configuration file. * disallowNewKeysInSubsequentConfigs(): All keys for this array must be defined in one configuration file, subsequent configurations may only overwrite these. * fixXmlConfig($key, $plural = null): Transforms XML config into same structure as YAML, and PHP configurations. * useAttributeAsKey($name): Defines which XML attribute to use as array key. * cannotBeOverwritten(): Declares a certain sub-path as non-overwritable. All configuration for this path must be defined in the same configuration file. * cannotBeEmpty(): If value is set, it must be non-empty. * canBeUnset(): If array values should be unset if false is specified. Architecture: ============= The configuration consists basically out of two different sets of classes. 1. Builder classes: These classes provide the fluent interface and are used to construct the config tree. 2. Node classes: These classes contain the actual logic for normalization, merging, and finalizing configurations. After you have added all the metadata to your builders, the call to ->buildTree() will convert this metadata to actual node classes. Most of the time, you will not have to interact with the config nodes directly, but will delegate this to the Processor class which will call the respective methods on the config node classes.
2011-02-04 13:37:01 +00:00
public function __construct($name, NodeInterface $parent = null)
{
[Security/DependencyInjection] adds support for merging security configurations The merging is done in three steps: 1. Normalization: ================= All passed config arrays will be transformed into the same structure regardless of what format they come from. 2. Merging: =========== This is the step when the actual merging is performed. Starting at the root the configs will be passed along the tree until a node has no children, or the merging of sub-paths of the current node has been specifically disabled. Left-Side Right-Side Merge Result ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -nothing- array Right-Side will be taken. scalar scalar Right-Side will be taken. array false Right-Side will be taken if ->canBeUnset() was called on the array node. false array Right-Side will be taken. array array Each value in the array will be passed to the specific child node, or the prototype node (whatever is present). 3. Finalization: ================ The normalized, and merged config will be passed through the config tree to perform final validation on the submitted values, and set default values where this has been requested. You can influence this process in various ways, here is a list with some examples. All of these methods must be called on the node on which they should be applied. * isRequired(): Node must be present in at least one config file. * requiresAtLeastOneElement(): PrototypeNode must have at least one element. * treatNullLike($value): Replaces null with $value during normalization. * treatTrueLike($value): Same as above just for true * treatFalseLike($value): Same as above just for false * defaultValue($value): Sets a default value for this node (only for scalars) * addDefaultsIfNotSet(): Whether to add default values of an array which has not been defined in any configuration file. * disallowNewKeysInSubsequentConfigs(): All keys for this array must be defined in one configuration file, subsequent configurations may only overwrite these. * fixXmlConfig($key, $plural = null): Transforms XML config into same structure as YAML, and PHP configurations. * useAttributeAsKey($name): Defines which XML attribute to use as array key. * cannotBeOverwritten(): Declares a certain sub-path as non-overwritable. All configuration for this path must be defined in the same configuration file. * cannotBeEmpty(): If value is set, it must be non-empty. * canBeUnset(): If array values should be unset if false is specified. Architecture: ============= The configuration consists basically out of two different sets of classes. 1. Builder classes: These classes provide the fluent interface and are used to construct the config tree. 2. Node classes: These classes contain the actual logic for normalization, merging, and finalizing configurations. After you have added all the metadata to your builders, the call to ->buildTree() will convert this metadata to actual node classes. Most of the time, you will not have to interact with the config nodes directly, but will delegate this to the Processor class which will call the respective methods on the config node classes.
2011-02-04 13:37:01 +00:00
parent::__construct($name, $parent);
$this->children = array();
[Security/DependencyInjection] adds support for merging security configurations The merging is done in three steps: 1. Normalization: ================= All passed config arrays will be transformed into the same structure regardless of what format they come from. 2. Merging: =========== This is the step when the actual merging is performed. Starting at the root the configs will be passed along the tree until a node has no children, or the merging of sub-paths of the current node has been specifically disabled. Left-Side Right-Side Merge Result ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -nothing- array Right-Side will be taken. scalar scalar Right-Side will be taken. array false Right-Side will be taken if ->canBeUnset() was called on the array node. false array Right-Side will be taken. array array Each value in the array will be passed to the specific child node, or the prototype node (whatever is present). 3. Finalization: ================ The normalized, and merged config will be passed through the config tree to perform final validation on the submitted values, and set default values where this has been requested. You can influence this process in various ways, here is a list with some examples. All of these methods must be called on the node on which they should be applied. * isRequired(): Node must be present in at least one config file. * requiresAtLeastOneElement(): PrototypeNode must have at least one element. * treatNullLike($value): Replaces null with $value during normalization. * treatTrueLike($value): Same as above just for true * treatFalseLike($value): Same as above just for false * defaultValue($value): Sets a default value for this node (only for scalars) * addDefaultsIfNotSet(): Whether to add default values of an array which has not been defined in any configuration file. * disallowNewKeysInSubsequentConfigs(): All keys for this array must be defined in one configuration file, subsequent configurations may only overwrite these. * fixXmlConfig($key, $plural = null): Transforms XML config into same structure as YAML, and PHP configurations. * useAttributeAsKey($name): Defines which XML attribute to use as array key. * cannotBeOverwritten(): Declares a certain sub-path as non-overwritable. All configuration for this path must be defined in the same configuration file. * cannotBeEmpty(): If value is set, it must be non-empty. * canBeUnset(): If array values should be unset if false is specified. Architecture: ============= The configuration consists basically out of two different sets of classes. 1. Builder classes: These classes provide the fluent interface and are used to construct the config tree. 2. Node classes: These classes contain the actual logic for normalization, merging, and finalizing configurations. After you have added all the metadata to your builders, the call to ->buildTree() will convert this metadata to actual node classes. Most of the time, you will not have to interact with the config nodes directly, but will delegate this to the Processor class which will call the respective methods on the config node classes.
2011-02-04 13:37:01 +00:00
$this->xmlRemappings = array();
$this->removeKeyAttribute = true;
[Security/DependencyInjection] adds support for merging security configurations The merging is done in three steps: 1. Normalization: ================= All passed config arrays will be transformed into the same structure regardless of what format they come from. 2. Merging: =========== This is the step when the actual merging is performed. Starting at the root the configs will be passed along the tree until a node has no children, or the merging of sub-paths of the current node has been specifically disabled. Left-Side Right-Side Merge Result ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -nothing- array Right-Side will be taken. scalar scalar Right-Side will be taken. array false Right-Side will be taken if ->canBeUnset() was called on the array node. false array Right-Side will be taken. array array Each value in the array will be passed to the specific child node, or the prototype node (whatever is present). 3. Finalization: ================ The normalized, and merged config will be passed through the config tree to perform final validation on the submitted values, and set default values where this has been requested. You can influence this process in various ways, here is a list with some examples. All of these methods must be called on the node on which they should be applied. * isRequired(): Node must be present in at least one config file. * requiresAtLeastOneElement(): PrototypeNode must have at least one element. * treatNullLike($value): Replaces null with $value during normalization. * treatTrueLike($value): Same as above just for true * treatFalseLike($value): Same as above just for false * defaultValue($value): Sets a default value for this node (only for scalars) * addDefaultsIfNotSet(): Whether to add default values of an array which has not been defined in any configuration file. * disallowNewKeysInSubsequentConfigs(): All keys for this array must be defined in one configuration file, subsequent configurations may only overwrite these. * fixXmlConfig($key, $plural = null): Transforms XML config into same structure as YAML, and PHP configurations. * useAttributeAsKey($name): Defines which XML attribute to use as array key. * cannotBeOverwritten(): Declares a certain sub-path as non-overwritable. All configuration for this path must be defined in the same configuration file. * cannotBeEmpty(): If value is set, it must be non-empty. * canBeUnset(): If array values should be unset if false is specified. Architecture: ============= The configuration consists basically out of two different sets of classes. 1. Builder classes: These classes provide the fluent interface and are used to construct the config tree. 2. Node classes: These classes contain the actual logic for normalization, merging, and finalizing configurations. After you have added all the metadata to your builders, the call to ->buildTree() will convert this metadata to actual node classes. Most of the time, you will not have to interact with the config nodes directly, but will delegate this to the Processor class which will call the respective methods on the config node classes.
2011-02-04 13:37:01 +00:00
$this->allowFalse = false;
$this->addIfNotSet = false;
$this->allowNewKeys = true;
$this->performDeepMerging = true;
$this->normalizeKeys = true;
}
public function setNormalizeKeys($normalizeKeys)
{
$this->normalizeKeys = (bool) $normalizeKeys;
}
/**
* Normalizes keys between the different configuration formats.
*
* Namely, you mostly have foo_bar in YAML while you have foo-bar in XML.
* After running this method, all keys are normalized to foo_bar.
*
* If you have a mixed key like foo-bar_moo, it will not be altered.
* The key will also not be altered if the target key already exists.
*
* @param mixed $value
*
* @return array The value with normalized keys
*/
protected function preNormalize($value)
{
if (!$this->normalizeKeys || !is_array($value)) {
return $value;
}
foreach ($value as $k => $v) {
if (false !== strpos($k, '-') && false === strpos($k, '_') && !array_key_exists($normalizedKey = str_replace('-', '_', $k), $value)) {
$value[$normalizedKey] = $v;
unset($value[$k]);
}
}
return $value;
[Security/DependencyInjection] adds support for merging security configurations The merging is done in three steps: 1. Normalization: ================= All passed config arrays will be transformed into the same structure regardless of what format they come from. 2. Merging: =========== This is the step when the actual merging is performed. Starting at the root the configs will be passed along the tree until a node has no children, or the merging of sub-paths of the current node has been specifically disabled. Left-Side Right-Side Merge Result ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -nothing- array Right-Side will be taken. scalar scalar Right-Side will be taken. array false Right-Side will be taken if ->canBeUnset() was called on the array node. false array Right-Side will be taken. array array Each value in the array will be passed to the specific child node, or the prototype node (whatever is present). 3. Finalization: ================ The normalized, and merged config will be passed through the config tree to perform final validation on the submitted values, and set default values where this has been requested. You can influence this process in various ways, here is a list with some examples. All of these methods must be called on the node on which they should be applied. * isRequired(): Node must be present in at least one config file. * requiresAtLeastOneElement(): PrototypeNode must have at least one element. * treatNullLike($value): Replaces null with $value during normalization. * treatTrueLike($value): Same as above just for true * treatFalseLike($value): Same as above just for false * defaultValue($value): Sets a default value for this node (only for scalars) * addDefaultsIfNotSet(): Whether to add default values of an array which has not been defined in any configuration file. * disallowNewKeysInSubsequentConfigs(): All keys for this array must be defined in one configuration file, subsequent configurations may only overwrite these. * fixXmlConfig($key, $plural = null): Transforms XML config into same structure as YAML, and PHP configurations. * useAttributeAsKey($name): Defines which XML attribute to use as array key. * cannotBeOverwritten(): Declares a certain sub-path as non-overwritable. All configuration for this path must be defined in the same configuration file. * cannotBeEmpty(): If value is set, it must be non-empty. * canBeUnset(): If array values should be unset if false is specified. Architecture: ============= The configuration consists basically out of two different sets of classes. 1. Builder classes: These classes provide the fluent interface and are used to construct the config tree. 2. Node classes: These classes contain the actual logic for normalization, merging, and finalizing configurations. After you have added all the metadata to your builders, the call to ->buildTree() will convert this metadata to actual node classes. Most of the time, you will not have to interact with the config nodes directly, but will delegate this to the Processor class which will call the respective methods on the config node classes.
2011-02-04 13:37:01 +00:00
}
2011-12-18 13:33:54 +00:00
/**
* Retrieves the children of this node.
2011-12-18 13:33:54 +00:00
*
* @return array The children
*/
public function getChildren()
{
return $this->children;
}
[Security/DependencyInjection] adds support for merging security configurations The merging is done in three steps: 1. Normalization: ================= All passed config arrays will be transformed into the same structure regardless of what format they come from. 2. Merging: =========== This is the step when the actual merging is performed. Starting at the root the configs will be passed along the tree until a node has no children, or the merging of sub-paths of the current node has been specifically disabled. Left-Side Right-Side Merge Result ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -nothing- array Right-Side will be taken. scalar scalar Right-Side will be taken. array false Right-Side will be taken if ->canBeUnset() was called on the array node. false array Right-Side will be taken. array array Each value in the array will be passed to the specific child node, or the prototype node (whatever is present). 3. Finalization: ================ The normalized, and merged config will be passed through the config tree to perform final validation on the submitted values, and set default values where this has been requested. You can influence this process in various ways, here is a list with some examples. All of these methods must be called on the node on which they should be applied. * isRequired(): Node must be present in at least one config file. * requiresAtLeastOneElement(): PrototypeNode must have at least one element. * treatNullLike($value): Replaces null with $value during normalization. * treatTrueLike($value): Same as above just for true * treatFalseLike($value): Same as above just for false * defaultValue($value): Sets a default value for this node (only for scalars) * addDefaultsIfNotSet(): Whether to add default values of an array which has not been defined in any configuration file. * disallowNewKeysInSubsequentConfigs(): All keys for this array must be defined in one configuration file, subsequent configurations may only overwrite these. * fixXmlConfig($key, $plural = null): Transforms XML config into same structure as YAML, and PHP configurations. * useAttributeAsKey($name): Defines which XML attribute to use as array key. * cannotBeOverwritten(): Declares a certain sub-path as non-overwritable. All configuration for this path must be defined in the same configuration file. * cannotBeEmpty(): If value is set, it must be non-empty. * canBeUnset(): If array values should be unset if false is specified. Architecture: ============= The configuration consists basically out of two different sets of classes. 1. Builder classes: These classes provide the fluent interface and are used to construct the config tree. 2. Node classes: These classes contain the actual logic for normalization, merging, and finalizing configurations. After you have added all the metadata to your builders, the call to ->buildTree() will convert this metadata to actual node classes. Most of the time, you will not have to interact with the config nodes directly, but will delegate this to the Processor class which will call the respective methods on the config node classes.
2011-02-04 13:37:01 +00:00
/**
* Sets the xml remappings that should be performed.
*
* @param array $remappings an array of the form array(array(string, string))
*/
public function setXmlRemappings(array $remappings)
{
$this->xmlRemappings = $remappings;
}
/**
* Sets whether to add default values for this array if it has not been
* defined in any of the configuration files.
*
2014-11-30 13:33:44 +00:00
* @param bool $boolean
[Security/DependencyInjection] adds support for merging security configurations The merging is done in three steps: 1. Normalization: ================= All passed config arrays will be transformed into the same structure regardless of what format they come from. 2. Merging: =========== This is the step when the actual merging is performed. Starting at the root the configs will be passed along the tree until a node has no children, or the merging of sub-paths of the current node has been specifically disabled. Left-Side Right-Side Merge Result ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -nothing- array Right-Side will be taken. scalar scalar Right-Side will be taken. array false Right-Side will be taken if ->canBeUnset() was called on the array node. false array Right-Side will be taken. array array Each value in the array will be passed to the specific child node, or the prototype node (whatever is present). 3. Finalization: ================ The normalized, and merged config will be passed through the config tree to perform final validation on the submitted values, and set default values where this has been requested. You can influence this process in various ways, here is a list with some examples. All of these methods must be called on the node on which they should be applied. * isRequired(): Node must be present in at least one config file. * requiresAtLeastOneElement(): PrototypeNode must have at least one element. * treatNullLike($value): Replaces null with $value during normalization. * treatTrueLike($value): Same as above just for true * treatFalseLike($value): Same as above just for false * defaultValue($value): Sets a default value for this node (only for scalars) * addDefaultsIfNotSet(): Whether to add default values of an array which has not been defined in any configuration file. * disallowNewKeysInSubsequentConfigs(): All keys for this array must be defined in one configuration file, subsequent configurations may only overwrite these. * fixXmlConfig($key, $plural = null): Transforms XML config into same structure as YAML, and PHP configurations. * useAttributeAsKey($name): Defines which XML attribute to use as array key. * cannotBeOverwritten(): Declares a certain sub-path as non-overwritable. All configuration for this path must be defined in the same configuration file. * cannotBeEmpty(): If value is set, it must be non-empty. * canBeUnset(): If array values should be unset if false is specified. Architecture: ============= The configuration consists basically out of two different sets of classes. 1. Builder classes: These classes provide the fluent interface and are used to construct the config tree. 2. Node classes: These classes contain the actual logic for normalization, merging, and finalizing configurations. After you have added all the metadata to your builders, the call to ->buildTree() will convert this metadata to actual node classes. Most of the time, you will not have to interact with the config nodes directly, but will delegate this to the Processor class which will call the respective methods on the config node classes.
2011-02-04 13:37:01 +00:00
*/
public function setAddIfNotSet($boolean)
{
$this->addIfNotSet = (bool) $boolean;
[Security/DependencyInjection] adds support for merging security configurations The merging is done in three steps: 1. Normalization: ================= All passed config arrays will be transformed into the same structure regardless of what format they come from. 2. Merging: =========== This is the step when the actual merging is performed. Starting at the root the configs will be passed along the tree until a node has no children, or the merging of sub-paths of the current node has been specifically disabled. Left-Side Right-Side Merge Result ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -nothing- array Right-Side will be taken. scalar scalar Right-Side will be taken. array false Right-Side will be taken if ->canBeUnset() was called on the array node. false array Right-Side will be taken. array array Each value in the array will be passed to the specific child node, or the prototype node (whatever is present). 3. Finalization: ================ The normalized, and merged config will be passed through the config tree to perform final validation on the submitted values, and set default values where this has been requested. You can influence this process in various ways, here is a list with some examples. All of these methods must be called on the node on which they should be applied. * isRequired(): Node must be present in at least one config file. * requiresAtLeastOneElement(): PrototypeNode must have at least one element. * treatNullLike($value): Replaces null with $value during normalization. * treatTrueLike($value): Same as above just for true * treatFalseLike($value): Same as above just for false * defaultValue($value): Sets a default value for this node (only for scalars) * addDefaultsIfNotSet(): Whether to add default values of an array which has not been defined in any configuration file. * disallowNewKeysInSubsequentConfigs(): All keys for this array must be defined in one configuration file, subsequent configurations may only overwrite these. * fixXmlConfig($key, $plural = null): Transforms XML config into same structure as YAML, and PHP configurations. * useAttributeAsKey($name): Defines which XML attribute to use as array key. * cannotBeOverwritten(): Declares a certain sub-path as non-overwritable. All configuration for this path must be defined in the same configuration file. * cannotBeEmpty(): If value is set, it must be non-empty. * canBeUnset(): If array values should be unset if false is specified. Architecture: ============= The configuration consists basically out of two different sets of classes. 1. Builder classes: These classes provide the fluent interface and are used to construct the config tree. 2. Node classes: These classes contain the actual logic for normalization, merging, and finalizing configurations. After you have added all the metadata to your builders, the call to ->buildTree() will convert this metadata to actual node classes. Most of the time, you will not have to interact with the config nodes directly, but will delegate this to the Processor class which will call the respective methods on the config node classes.
2011-02-04 13:37:01 +00:00
}
/**
2011-12-13 07:50:54 +00:00
* Sets whether false is allowed as value indicating that the array should be unset.
[Security/DependencyInjection] adds support for merging security configurations The merging is done in three steps: 1. Normalization: ================= All passed config arrays will be transformed into the same structure regardless of what format they come from. 2. Merging: =========== This is the step when the actual merging is performed. Starting at the root the configs will be passed along the tree until a node has no children, or the merging of sub-paths of the current node has been specifically disabled. Left-Side Right-Side Merge Result ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -nothing- array Right-Side will be taken. scalar scalar Right-Side will be taken. array false Right-Side will be taken if ->canBeUnset() was called on the array node. false array Right-Side will be taken. array array Each value in the array will be passed to the specific child node, or the prototype node (whatever is present). 3. Finalization: ================ The normalized, and merged config will be passed through the config tree to perform final validation on the submitted values, and set default values where this has been requested. You can influence this process in various ways, here is a list with some examples. All of these methods must be called on the node on which they should be applied. * isRequired(): Node must be present in at least one config file. * requiresAtLeastOneElement(): PrototypeNode must have at least one element. * treatNullLike($value): Replaces null with $value during normalization. * treatTrueLike($value): Same as above just for true * treatFalseLike($value): Same as above just for false * defaultValue($value): Sets a default value for this node (only for scalars) * addDefaultsIfNotSet(): Whether to add default values of an array which has not been defined in any configuration file. * disallowNewKeysInSubsequentConfigs(): All keys for this array must be defined in one configuration file, subsequent configurations may only overwrite these. * fixXmlConfig($key, $plural = null): Transforms XML config into same structure as YAML, and PHP configurations. * useAttributeAsKey($name): Defines which XML attribute to use as array key. * cannotBeOverwritten(): Declares a certain sub-path as non-overwritable. All configuration for this path must be defined in the same configuration file. * cannotBeEmpty(): If value is set, it must be non-empty. * canBeUnset(): If array values should be unset if false is specified. Architecture: ============= The configuration consists basically out of two different sets of classes. 1. Builder classes: These classes provide the fluent interface and are used to construct the config tree. 2. Node classes: These classes contain the actual logic for normalization, merging, and finalizing configurations. After you have added all the metadata to your builders, the call to ->buildTree() will convert this metadata to actual node classes. Most of the time, you will not have to interact with the config nodes directly, but will delegate this to the Processor class which will call the respective methods on the config node classes.
2011-02-04 13:37:01 +00:00
*
2014-11-30 13:33:44 +00:00
* @param bool $allow
[Security/DependencyInjection] adds support for merging security configurations The merging is done in three steps: 1. Normalization: ================= All passed config arrays will be transformed into the same structure regardless of what format they come from. 2. Merging: =========== This is the step when the actual merging is performed. Starting at the root the configs will be passed along the tree until a node has no children, or the merging of sub-paths of the current node has been specifically disabled. Left-Side Right-Side Merge Result ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -nothing- array Right-Side will be taken. scalar scalar Right-Side will be taken. array false Right-Side will be taken if ->canBeUnset() was called on the array node. false array Right-Side will be taken. array array Each value in the array will be passed to the specific child node, or the prototype node (whatever is present). 3. Finalization: ================ The normalized, and merged config will be passed through the config tree to perform final validation on the submitted values, and set default values where this has been requested. You can influence this process in various ways, here is a list with some examples. All of these methods must be called on the node on which they should be applied. * isRequired(): Node must be present in at least one config file. * requiresAtLeastOneElement(): PrototypeNode must have at least one element. * treatNullLike($value): Replaces null with $value during normalization. * treatTrueLike($value): Same as above just for true * treatFalseLike($value): Same as above just for false * defaultValue($value): Sets a default value for this node (only for scalars) * addDefaultsIfNotSet(): Whether to add default values of an array which has not been defined in any configuration file. * disallowNewKeysInSubsequentConfigs(): All keys for this array must be defined in one configuration file, subsequent configurations may only overwrite these. * fixXmlConfig($key, $plural = null): Transforms XML config into same structure as YAML, and PHP configurations. * useAttributeAsKey($name): Defines which XML attribute to use as array key. * cannotBeOverwritten(): Declares a certain sub-path as non-overwritable. All configuration for this path must be defined in the same configuration file. * cannotBeEmpty(): If value is set, it must be non-empty. * canBeUnset(): If array values should be unset if false is specified. Architecture: ============= The configuration consists basically out of two different sets of classes. 1. Builder classes: These classes provide the fluent interface and are used to construct the config tree. 2. Node classes: These classes contain the actual logic for normalization, merging, and finalizing configurations. After you have added all the metadata to your builders, the call to ->buildTree() will convert this metadata to actual node classes. Most of the time, you will not have to interact with the config nodes directly, but will delegate this to the Processor class which will call the respective methods on the config node classes.
2011-02-04 13:37:01 +00:00
*/
public function setAllowFalse($allow)
{
$this->allowFalse = (bool) $allow;
[Security/DependencyInjection] adds support for merging security configurations The merging is done in three steps: 1. Normalization: ================= All passed config arrays will be transformed into the same structure regardless of what format they come from. 2. Merging: =========== This is the step when the actual merging is performed. Starting at the root the configs will be passed along the tree until a node has no children, or the merging of sub-paths of the current node has been specifically disabled. Left-Side Right-Side Merge Result ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -nothing- array Right-Side will be taken. scalar scalar Right-Side will be taken. array false Right-Side will be taken if ->canBeUnset() was called on the array node. false array Right-Side will be taken. array array Each value in the array will be passed to the specific child node, or the prototype node (whatever is present). 3. Finalization: ================ The normalized, and merged config will be passed through the config tree to perform final validation on the submitted values, and set default values where this has been requested. You can influence this process in various ways, here is a list with some examples. All of these methods must be called on the node on which they should be applied. * isRequired(): Node must be present in at least one config file. * requiresAtLeastOneElement(): PrototypeNode must have at least one element. * treatNullLike($value): Replaces null with $value during normalization. * treatTrueLike($value): Same as above just for true * treatFalseLike($value): Same as above just for false * defaultValue($value): Sets a default value for this node (only for scalars) * addDefaultsIfNotSet(): Whether to add default values of an array which has not been defined in any configuration file. * disallowNewKeysInSubsequentConfigs(): All keys for this array must be defined in one configuration file, subsequent configurations may only overwrite these. * fixXmlConfig($key, $plural = null): Transforms XML config into same structure as YAML, and PHP configurations. * useAttributeAsKey($name): Defines which XML attribute to use as array key. * cannotBeOverwritten(): Declares a certain sub-path as non-overwritable. All configuration for this path must be defined in the same configuration file. * cannotBeEmpty(): If value is set, it must be non-empty. * canBeUnset(): If array values should be unset if false is specified. Architecture: ============= The configuration consists basically out of two different sets of classes. 1. Builder classes: These classes provide the fluent interface and are used to construct the config tree. 2. Node classes: These classes contain the actual logic for normalization, merging, and finalizing configurations. After you have added all the metadata to your builders, the call to ->buildTree() will convert this metadata to actual node classes. Most of the time, you will not have to interact with the config nodes directly, but will delegate this to the Processor class which will call the respective methods on the config node classes.
2011-02-04 13:37:01 +00:00
}
/**
* Sets whether new keys can be defined in subsequent configurations.
*
2014-11-30 13:33:44 +00:00
* @param bool $allow
[Security/DependencyInjection] adds support for merging security configurations The merging is done in three steps: 1. Normalization: ================= All passed config arrays will be transformed into the same structure regardless of what format they come from. 2. Merging: =========== This is the step when the actual merging is performed. Starting at the root the configs will be passed along the tree until a node has no children, or the merging of sub-paths of the current node has been specifically disabled. Left-Side Right-Side Merge Result ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -nothing- array Right-Side will be taken. scalar scalar Right-Side will be taken. array false Right-Side will be taken if ->canBeUnset() was called on the array node. false array Right-Side will be taken. array array Each value in the array will be passed to the specific child node, or the prototype node (whatever is present). 3. Finalization: ================ The normalized, and merged config will be passed through the config tree to perform final validation on the submitted values, and set default values where this has been requested. You can influence this process in various ways, here is a list with some examples. All of these methods must be called on the node on which they should be applied. * isRequired(): Node must be present in at least one config file. * requiresAtLeastOneElement(): PrototypeNode must have at least one element. * treatNullLike($value): Replaces null with $value during normalization. * treatTrueLike($value): Same as above just for true * treatFalseLike($value): Same as above just for false * defaultValue($value): Sets a default value for this node (only for scalars) * addDefaultsIfNotSet(): Whether to add default values of an array which has not been defined in any configuration file. * disallowNewKeysInSubsequentConfigs(): All keys for this array must be defined in one configuration file, subsequent configurations may only overwrite these. * fixXmlConfig($key, $plural = null): Transforms XML config into same structure as YAML, and PHP configurations. * useAttributeAsKey($name): Defines which XML attribute to use as array key. * cannotBeOverwritten(): Declares a certain sub-path as non-overwritable. All configuration for this path must be defined in the same configuration file. * cannotBeEmpty(): If value is set, it must be non-empty. * canBeUnset(): If array values should be unset if false is specified. Architecture: ============= The configuration consists basically out of two different sets of classes. 1. Builder classes: These classes provide the fluent interface and are used to construct the config tree. 2. Node classes: These classes contain the actual logic for normalization, merging, and finalizing configurations. After you have added all the metadata to your builders, the call to ->buildTree() will convert this metadata to actual node classes. Most of the time, you will not have to interact with the config nodes directly, but will delegate this to the Processor class which will call the respective methods on the config node classes.
2011-02-04 13:37:01 +00:00
*/
public function setAllowNewKeys($allow)
{
$this->allowNewKeys = (bool) $allow;
[Security/DependencyInjection] adds support for merging security configurations The merging is done in three steps: 1. Normalization: ================= All passed config arrays will be transformed into the same structure regardless of what format they come from. 2. Merging: =========== This is the step when the actual merging is performed. Starting at the root the configs will be passed along the tree until a node has no children, or the merging of sub-paths of the current node has been specifically disabled. Left-Side Right-Side Merge Result ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -nothing- array Right-Side will be taken. scalar scalar Right-Side will be taken. array false Right-Side will be taken if ->canBeUnset() was called on the array node. false array Right-Side will be taken. array array Each value in the array will be passed to the specific child node, or the prototype node (whatever is present). 3. Finalization: ================ The normalized, and merged config will be passed through the config tree to perform final validation on the submitted values, and set default values where this has been requested. You can influence this process in various ways, here is a list with some examples. All of these methods must be called on the node on which they should be applied. * isRequired(): Node must be present in at least one config file. * requiresAtLeastOneElement(): PrototypeNode must have at least one element. * treatNullLike($value): Replaces null with $value during normalization. * treatTrueLike($value): Same as above just for true * treatFalseLike($value): Same as above just for false * defaultValue($value): Sets a default value for this node (only for scalars) * addDefaultsIfNotSet(): Whether to add default values of an array which has not been defined in any configuration file. * disallowNewKeysInSubsequentConfigs(): All keys for this array must be defined in one configuration file, subsequent configurations may only overwrite these. * fixXmlConfig($key, $plural = null): Transforms XML config into same structure as YAML, and PHP configurations. * useAttributeAsKey($name): Defines which XML attribute to use as array key. * cannotBeOverwritten(): Declares a certain sub-path as non-overwritable. All configuration for this path must be defined in the same configuration file. * cannotBeEmpty(): If value is set, it must be non-empty. * canBeUnset(): If array values should be unset if false is specified. Architecture: ============= The configuration consists basically out of two different sets of classes. 1. Builder classes: These classes provide the fluent interface and are used to construct the config tree. 2. Node classes: These classes contain the actual logic for normalization, merging, and finalizing configurations. After you have added all the metadata to your builders, the call to ->buildTree() will convert this metadata to actual node classes. Most of the time, you will not have to interact with the config nodes directly, but will delegate this to the Processor class which will call the respective methods on the config node classes.
2011-02-04 13:37:01 +00:00
}
2011-02-13 18:06:41 +00:00
/**
* Sets if deep merging should occur.
*
2014-11-30 13:33:44 +00:00
* @param bool $boolean
2011-02-13 18:06:41 +00:00
*/
[Security/DependencyInjection] adds support for merging security configurations The merging is done in three steps: 1. Normalization: ================= All passed config arrays will be transformed into the same structure regardless of what format they come from. 2. Merging: =========== This is the step when the actual merging is performed. Starting at the root the configs will be passed along the tree until a node has no children, or the merging of sub-paths of the current node has been specifically disabled. Left-Side Right-Side Merge Result ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -nothing- array Right-Side will be taken. scalar scalar Right-Side will be taken. array false Right-Side will be taken if ->canBeUnset() was called on the array node. false array Right-Side will be taken. array array Each value in the array will be passed to the specific child node, or the prototype node (whatever is present). 3. Finalization: ================ The normalized, and merged config will be passed through the config tree to perform final validation on the submitted values, and set default values where this has been requested. You can influence this process in various ways, here is a list with some examples. All of these methods must be called on the node on which they should be applied. * isRequired(): Node must be present in at least one config file. * requiresAtLeastOneElement(): PrototypeNode must have at least one element. * treatNullLike($value): Replaces null with $value during normalization. * treatTrueLike($value): Same as above just for true * treatFalseLike($value): Same as above just for false * defaultValue($value): Sets a default value for this node (only for scalars) * addDefaultsIfNotSet(): Whether to add default values of an array which has not been defined in any configuration file. * disallowNewKeysInSubsequentConfigs(): All keys for this array must be defined in one configuration file, subsequent configurations may only overwrite these. * fixXmlConfig($key, $plural = null): Transforms XML config into same structure as YAML, and PHP configurations. * useAttributeAsKey($name): Defines which XML attribute to use as array key. * cannotBeOverwritten(): Declares a certain sub-path as non-overwritable. All configuration for this path must be defined in the same configuration file. * cannotBeEmpty(): If value is set, it must be non-empty. * canBeUnset(): If array values should be unset if false is specified. Architecture: ============= The configuration consists basically out of two different sets of classes. 1. Builder classes: These classes provide the fluent interface and are used to construct the config tree. 2. Node classes: These classes contain the actual logic for normalization, merging, and finalizing configurations. After you have added all the metadata to your builders, the call to ->buildTree() will convert this metadata to actual node classes. Most of the time, you will not have to interact with the config nodes directly, but will delegate this to the Processor class which will call the respective methods on the config node classes.
2011-02-04 13:37:01 +00:00
public function setPerformDeepMerging($boolean)
{
$this->performDeepMerging = (bool) $boolean;
}
/**
* Whether extra keys should just be ignore without an exception.
*
2014-11-30 13:33:44 +00:00
* @param bool $boolean To allow extra keys
*/
public function setIgnoreExtraKeys($boolean)
{
$this->ignoreExtraKeys = (bool) $boolean;
}
2011-02-13 18:06:41 +00:00
/**
* Sets the node Name.
*
* @param string $name The node's name
*/
public function setName($name)
{
$this->name = $name;
}
2011-02-13 18:06:41 +00:00
/**
* Checks if the node has a default value.
*
2014-04-16 11:30:19 +01:00
* @return bool
2011-02-13 18:06:41 +00:00
*/
[Security/DependencyInjection] adds support for merging security configurations The merging is done in three steps: 1. Normalization: ================= All passed config arrays will be transformed into the same structure regardless of what format they come from. 2. Merging: =========== This is the step when the actual merging is performed. Starting at the root the configs will be passed along the tree until a node has no children, or the merging of sub-paths of the current node has been specifically disabled. Left-Side Right-Side Merge Result ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -nothing- array Right-Side will be taken. scalar scalar Right-Side will be taken. array false Right-Side will be taken if ->canBeUnset() was called on the array node. false array Right-Side will be taken. array array Each value in the array will be passed to the specific child node, or the prototype node (whatever is present). 3. Finalization: ================ The normalized, and merged config will be passed through the config tree to perform final validation on the submitted values, and set default values where this has been requested. You can influence this process in various ways, here is a list with some examples. All of these methods must be called on the node on which they should be applied. * isRequired(): Node must be present in at least one config file. * requiresAtLeastOneElement(): PrototypeNode must have at least one element. * treatNullLike($value): Replaces null with $value during normalization. * treatTrueLike($value): Same as above just for true * treatFalseLike($value): Same as above just for false * defaultValue($value): Sets a default value for this node (only for scalars) * addDefaultsIfNotSet(): Whether to add default values of an array which has not been defined in any configuration file. * disallowNewKeysInSubsequentConfigs(): All keys for this array must be defined in one configuration file, subsequent configurations may only overwrite these. * fixXmlConfig($key, $plural = null): Transforms XML config into same structure as YAML, and PHP configurations. * useAttributeAsKey($name): Defines which XML attribute to use as array key. * cannotBeOverwritten(): Declares a certain sub-path as non-overwritable. All configuration for this path must be defined in the same configuration file. * cannotBeEmpty(): If value is set, it must be non-empty. * canBeUnset(): If array values should be unset if false is specified. Architecture: ============= The configuration consists basically out of two different sets of classes. 1. Builder classes: These classes provide the fluent interface and are used to construct the config tree. 2. Node classes: These classes contain the actual logic for normalization, merging, and finalizing configurations. After you have added all the metadata to your builders, the call to ->buildTree() will convert this metadata to actual node classes. Most of the time, you will not have to interact with the config nodes directly, but will delegate this to the Processor class which will call the respective methods on the config node classes.
2011-02-04 13:37:01 +00:00
public function hasDefaultValue()
{
return $this->addIfNotSet;
}
2011-02-13 18:06:41 +00:00
/**
* Retrieves the default value.
*
* @return array The default value
2011-12-13 07:50:54 +00:00
*
2011-02-13 18:06:41 +00:00
* @throws \RuntimeException if the node has no default value
*/
[Security/DependencyInjection] adds support for merging security configurations The merging is done in three steps: 1. Normalization: ================= All passed config arrays will be transformed into the same structure regardless of what format they come from. 2. Merging: =========== This is the step when the actual merging is performed. Starting at the root the configs will be passed along the tree until a node has no children, or the merging of sub-paths of the current node has been specifically disabled. Left-Side Right-Side Merge Result ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -nothing- array Right-Side will be taken. scalar scalar Right-Side will be taken. array false Right-Side will be taken if ->canBeUnset() was called on the array node. false array Right-Side will be taken. array array Each value in the array will be passed to the specific child node, or the prototype node (whatever is present). 3. Finalization: ================ The normalized, and merged config will be passed through the config tree to perform final validation on the submitted values, and set default values where this has been requested. You can influence this process in various ways, here is a list with some examples. All of these methods must be called on the node on which they should be applied. * isRequired(): Node must be present in at least one config file. * requiresAtLeastOneElement(): PrototypeNode must have at least one element. * treatNullLike($value): Replaces null with $value during normalization. * treatTrueLike($value): Same as above just for true * treatFalseLike($value): Same as above just for false * defaultValue($value): Sets a default value for this node (only for scalars) * addDefaultsIfNotSet(): Whether to add default values of an array which has not been defined in any configuration file. * disallowNewKeysInSubsequentConfigs(): All keys for this array must be defined in one configuration file, subsequent configurations may only overwrite these. * fixXmlConfig($key, $plural = null): Transforms XML config into same structure as YAML, and PHP configurations. * useAttributeAsKey($name): Defines which XML attribute to use as array key. * cannotBeOverwritten(): Declares a certain sub-path as non-overwritable. All configuration for this path must be defined in the same configuration file. * cannotBeEmpty(): If value is set, it must be non-empty. * canBeUnset(): If array values should be unset if false is specified. Architecture: ============= The configuration consists basically out of two different sets of classes. 1. Builder classes: These classes provide the fluent interface and are used to construct the config tree. 2. Node classes: These classes contain the actual logic for normalization, merging, and finalizing configurations. After you have added all the metadata to your builders, the call to ->buildTree() will convert this metadata to actual node classes. Most of the time, you will not have to interact with the config nodes directly, but will delegate this to the Processor class which will call the respective methods on the config node classes.
2011-02-04 13:37:01 +00:00
public function getDefaultValue()
{
if (!$this->hasDefaultValue()) {
throw new \RuntimeException(sprintf('The node at path "%s" has no default value.', $this->getPath()));
}
$defaults = array();
foreach ($this->children as $name => $child) {
[Config] Component refactoring The Config component API have changed and the extension configuration files must be updated accordingly: 1. Array nodes must enclosed their children definition in ->children() ... ->end() calls: Before: $treeBuilder->root('zend', 'array') ->arrayNode('logger') ->scalarNode('priority')->defaultValue('INFO')->end() ->booleanNode('log_errors')->defaultFalse()->end() ->end(); After: $treeBuilder->root('zend', 'array') ->children() ->arrayNode('logger') ->children() ->scalarNode('priority')->defaultValue('INFO')->end() ->booleanNode('log_errors')->defaultFalse()->end() ->end() ->end() ->end(); 2. The 'builder' method (in NodeBuilder) has been dropped in favor of an 'append' method (in ArrayNodeDefinition) Before: $treeBuilder->root('doctrine', 'array') ->arrayNode('dbal') ->builder($this->getDbalConnectionsNode()) ->end(); After: $treeBuilder->root('doctrine', 'array') ->children() ->arrayNode('dbal') ->append($this->getDbalConnectionsNode()) ->end() ->end(); 3. The root of a TreeBuilder is now an NodeDefinition (and most probably an ArrayNodeDefinition): Before: $root = $treeBuilder->root('doctrine', 'array'); $this->addDbalSection($root); public function addDbalSection(NodeBuilder $node) { ... } After: $root = $treeBuilder->root('doctrine', 'array'); $this->addDbalSection($root); public function addDbalSection(ArrayNodeDefinition $node) { ... } 4. The NodeBuilder API has changed (this is seldom used): Before: $node = new NodeBuilder('connections', 'array'); After: The recommended way is to use a tree builder: $treeBuilder = new TreeBuilder(); $node = $treeBuilder->root('connections', 'array'); An other way would be: $builder = new NodeBuilder(); $node = $builder->node('connections', 'array'); Some notes: - Tree root nodes should most always be array nodes, so this as been made the default: $treeBuilder->root('doctrine', 'array') is equivalent to $treeBuilder->root('doctrine') - There could be more than one ->children() ... ->end() sections. This could help with the readability: $treeBuilder->root('doctrine') ->children() ->scalarNode('default_connection')->end() ->end() ->fixXmlConfig('type') ->children() ->arrayNode('types') .... ->end() ->end()
2011-03-14 17:29:56 +00:00
if ($child->hasDefaultValue()) {
$defaults[$name] = $child->getDefaultValue();
[Security/DependencyInjection] adds support for merging security configurations The merging is done in three steps: 1. Normalization: ================= All passed config arrays will be transformed into the same structure regardless of what format they come from. 2. Merging: =========== This is the step when the actual merging is performed. Starting at the root the configs will be passed along the tree until a node has no children, or the merging of sub-paths of the current node has been specifically disabled. Left-Side Right-Side Merge Result ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -nothing- array Right-Side will be taken. scalar scalar Right-Side will be taken. array false Right-Side will be taken if ->canBeUnset() was called on the array node. false array Right-Side will be taken. array array Each value in the array will be passed to the specific child node, or the prototype node (whatever is present). 3. Finalization: ================ The normalized, and merged config will be passed through the config tree to perform final validation on the submitted values, and set default values where this has been requested. You can influence this process in various ways, here is a list with some examples. All of these methods must be called on the node on which they should be applied. * isRequired(): Node must be present in at least one config file. * requiresAtLeastOneElement(): PrototypeNode must have at least one element. * treatNullLike($value): Replaces null with $value during normalization. * treatTrueLike($value): Same as above just for true * treatFalseLike($value): Same as above just for false * defaultValue($value): Sets a default value for this node (only for scalars) * addDefaultsIfNotSet(): Whether to add default values of an array which has not been defined in any configuration file. * disallowNewKeysInSubsequentConfigs(): All keys for this array must be defined in one configuration file, subsequent configurations may only overwrite these. * fixXmlConfig($key, $plural = null): Transforms XML config into same structure as YAML, and PHP configurations. * useAttributeAsKey($name): Defines which XML attribute to use as array key. * cannotBeOverwritten(): Declares a certain sub-path as non-overwritable. All configuration for this path must be defined in the same configuration file. * cannotBeEmpty(): If value is set, it must be non-empty. * canBeUnset(): If array values should be unset if false is specified. Architecture: ============= The configuration consists basically out of two different sets of classes. 1. Builder classes: These classes provide the fluent interface and are used to construct the config tree. 2. Node classes: These classes contain the actual logic for normalization, merging, and finalizing configurations. After you have added all the metadata to your builders, the call to ->buildTree() will convert this metadata to actual node classes. Most of the time, you will not have to interact with the config nodes directly, but will delegate this to the Processor class which will call the respective methods on the config node classes.
2011-02-04 13:37:01 +00:00
}
}
return $defaults;
}
2011-02-13 18:06:41 +00:00
/**
* Adds a child node.
*
* @param NodeInterface $node The child node to add
2011-12-13 07:50:54 +00:00
*
2011-02-13 18:06:41 +00:00
* @throws \InvalidArgumentException when the child node has no name
* @throws \InvalidArgumentException when the child node's name is not unique
*/
public function addChild(NodeInterface $node)
{
$name = $node->getName();
2013-12-04 22:06:34 +00:00
if (!strlen($name)) {
[Config] Component refactoring The Config component API have changed and the extension configuration files must be updated accordingly: 1. Array nodes must enclosed their children definition in ->children() ... ->end() calls: Before: $treeBuilder->root('zend', 'array') ->arrayNode('logger') ->scalarNode('priority')->defaultValue('INFO')->end() ->booleanNode('log_errors')->defaultFalse()->end() ->end(); After: $treeBuilder->root('zend', 'array') ->children() ->arrayNode('logger') ->children() ->scalarNode('priority')->defaultValue('INFO')->end() ->booleanNode('log_errors')->defaultFalse()->end() ->end() ->end() ->end(); 2. The 'builder' method (in NodeBuilder) has been dropped in favor of an 'append' method (in ArrayNodeDefinition) Before: $treeBuilder->root('doctrine', 'array') ->arrayNode('dbal') ->builder($this->getDbalConnectionsNode()) ->end(); After: $treeBuilder->root('doctrine', 'array') ->children() ->arrayNode('dbal') ->append($this->getDbalConnectionsNode()) ->end() ->end(); 3. The root of a TreeBuilder is now an NodeDefinition (and most probably an ArrayNodeDefinition): Before: $root = $treeBuilder->root('doctrine', 'array'); $this->addDbalSection($root); public function addDbalSection(NodeBuilder $node) { ... } After: $root = $treeBuilder->root('doctrine', 'array'); $this->addDbalSection($root); public function addDbalSection(ArrayNodeDefinition $node) { ... } 4. The NodeBuilder API has changed (this is seldom used): Before: $node = new NodeBuilder('connections', 'array'); After: The recommended way is to use a tree builder: $treeBuilder = new TreeBuilder(); $node = $treeBuilder->root('connections', 'array'); An other way would be: $builder = new NodeBuilder(); $node = $builder->node('connections', 'array'); Some notes: - Tree root nodes should most always be array nodes, so this as been made the default: $treeBuilder->root('doctrine', 'array') is equivalent to $treeBuilder->root('doctrine') - There could be more than one ->children() ... ->end() sections. This could help with the readability: $treeBuilder->root('doctrine') ->children() ->scalarNode('default_connection')->end() ->end() ->fixXmlConfig('type') ->children() ->arrayNode('types') .... ->end() ->end()
2011-03-14 17:29:56 +00:00
throw new \InvalidArgumentException('Child nodes must be named.');
}
if (isset($this->children[$name])) {
[Config] Component refactoring The Config component API have changed and the extension configuration files must be updated accordingly: 1. Array nodes must enclosed their children definition in ->children() ... ->end() calls: Before: $treeBuilder->root('zend', 'array') ->arrayNode('logger') ->scalarNode('priority')->defaultValue('INFO')->end() ->booleanNode('log_errors')->defaultFalse()->end() ->end(); After: $treeBuilder->root('zend', 'array') ->children() ->arrayNode('logger') ->children() ->scalarNode('priority')->defaultValue('INFO')->end() ->booleanNode('log_errors')->defaultFalse()->end() ->end() ->end() ->end(); 2. The 'builder' method (in NodeBuilder) has been dropped in favor of an 'append' method (in ArrayNodeDefinition) Before: $treeBuilder->root('doctrine', 'array') ->arrayNode('dbal') ->builder($this->getDbalConnectionsNode()) ->end(); After: $treeBuilder->root('doctrine', 'array') ->children() ->arrayNode('dbal') ->append($this->getDbalConnectionsNode()) ->end() ->end(); 3. The root of a TreeBuilder is now an NodeDefinition (and most probably an ArrayNodeDefinition): Before: $root = $treeBuilder->root('doctrine', 'array'); $this->addDbalSection($root); public function addDbalSection(NodeBuilder $node) { ... } After: $root = $treeBuilder->root('doctrine', 'array'); $this->addDbalSection($root); public function addDbalSection(ArrayNodeDefinition $node) { ... } 4. The NodeBuilder API has changed (this is seldom used): Before: $node = new NodeBuilder('connections', 'array'); After: The recommended way is to use a tree builder: $treeBuilder = new TreeBuilder(); $node = $treeBuilder->root('connections', 'array'); An other way would be: $builder = new NodeBuilder(); $node = $builder->node('connections', 'array'); Some notes: - Tree root nodes should most always be array nodes, so this as been made the default: $treeBuilder->root('doctrine', 'array') is equivalent to $treeBuilder->root('doctrine') - There could be more than one ->children() ... ->end() sections. This could help with the readability: $treeBuilder->root('doctrine') ->children() ->scalarNode('default_connection')->end() ->end() ->fixXmlConfig('type') ->children() ->arrayNode('types') .... ->end() ->end()
2011-03-14 17:29:56 +00:00
throw new \InvalidArgumentException(sprintf('A child node named "%s" already exists.', $name));
}
$this->children[$name] = $node;
}
2011-02-13 18:06:41 +00:00
/**
[Config] Component refactoring The Config component API have changed and the extension configuration files must be updated accordingly: 1. Array nodes must enclosed their children definition in ->children() ... ->end() calls: Before: $treeBuilder->root('zend', 'array') ->arrayNode('logger') ->scalarNode('priority')->defaultValue('INFO')->end() ->booleanNode('log_errors')->defaultFalse()->end() ->end(); After: $treeBuilder->root('zend', 'array') ->children() ->arrayNode('logger') ->children() ->scalarNode('priority')->defaultValue('INFO')->end() ->booleanNode('log_errors')->defaultFalse()->end() ->end() ->end() ->end(); 2. The 'builder' method (in NodeBuilder) has been dropped in favor of an 'append' method (in ArrayNodeDefinition) Before: $treeBuilder->root('doctrine', 'array') ->arrayNode('dbal') ->builder($this->getDbalConnectionsNode()) ->end(); After: $treeBuilder->root('doctrine', 'array') ->children() ->arrayNode('dbal') ->append($this->getDbalConnectionsNode()) ->end() ->end(); 3. The root of a TreeBuilder is now an NodeDefinition (and most probably an ArrayNodeDefinition): Before: $root = $treeBuilder->root('doctrine', 'array'); $this->addDbalSection($root); public function addDbalSection(NodeBuilder $node) { ... } After: $root = $treeBuilder->root('doctrine', 'array'); $this->addDbalSection($root); public function addDbalSection(ArrayNodeDefinition $node) { ... } 4. The NodeBuilder API has changed (this is seldom used): Before: $node = new NodeBuilder('connections', 'array'); After: The recommended way is to use a tree builder: $treeBuilder = new TreeBuilder(); $node = $treeBuilder->root('connections', 'array'); An other way would be: $builder = new NodeBuilder(); $node = $builder->node('connections', 'array'); Some notes: - Tree root nodes should most always be array nodes, so this as been made the default: $treeBuilder->root('doctrine', 'array') is equivalent to $treeBuilder->root('doctrine') - There could be more than one ->children() ... ->end() sections. This could help with the readability: $treeBuilder->root('doctrine') ->children() ->scalarNode('default_connection')->end() ->end() ->fixXmlConfig('type') ->children() ->arrayNode('types') .... ->end() ->end()
2011-03-14 17:29:56 +00:00
* Finalizes the value of this node.
2011-02-13 18:06:41 +00:00
*
* @param mixed $value
2011-12-13 07:50:54 +00:00
*
2011-02-13 18:06:41 +00:00
* @return mixed The finalised value
2011-12-13 07:50:54 +00:00
*
2011-02-13 18:06:41 +00:00
* @throws UnsetKeyException
2011-02-26 17:42:39 +00:00
* @throws InvalidConfigurationException if the node doesn't have enough children
2011-02-13 18:06:41 +00:00
*/
[Security/DependencyInjection] adds support for merging security configurations The merging is done in three steps: 1. Normalization: ================= All passed config arrays will be transformed into the same structure regardless of what format they come from. 2. Merging: =========== This is the step when the actual merging is performed. Starting at the root the configs will be passed along the tree until a node has no children, or the merging of sub-paths of the current node has been specifically disabled. Left-Side Right-Side Merge Result ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -nothing- array Right-Side will be taken. scalar scalar Right-Side will be taken. array false Right-Side will be taken if ->canBeUnset() was called on the array node. false array Right-Side will be taken. array array Each value in the array will be passed to the specific child node, or the prototype node (whatever is present). 3. Finalization: ================ The normalized, and merged config will be passed through the config tree to perform final validation on the submitted values, and set default values where this has been requested. You can influence this process in various ways, here is a list with some examples. All of these methods must be called on the node on which they should be applied. * isRequired(): Node must be present in at least one config file. * requiresAtLeastOneElement(): PrototypeNode must have at least one element. * treatNullLike($value): Replaces null with $value during normalization. * treatTrueLike($value): Same as above just for true * treatFalseLike($value): Same as above just for false * defaultValue($value): Sets a default value for this node (only for scalars) * addDefaultsIfNotSet(): Whether to add default values of an array which has not been defined in any configuration file. * disallowNewKeysInSubsequentConfigs(): All keys for this array must be defined in one configuration file, subsequent configurations may only overwrite these. * fixXmlConfig($key, $plural = null): Transforms XML config into same structure as YAML, and PHP configurations. * useAttributeAsKey($name): Defines which XML attribute to use as array key. * cannotBeOverwritten(): Declares a certain sub-path as non-overwritable. All configuration for this path must be defined in the same configuration file. * cannotBeEmpty(): If value is set, it must be non-empty. * canBeUnset(): If array values should be unset if false is specified. Architecture: ============= The configuration consists basically out of two different sets of classes. 1. Builder classes: These classes provide the fluent interface and are used to construct the config tree. 2. Node classes: These classes contain the actual logic for normalization, merging, and finalizing configurations. After you have added all the metadata to your builders, the call to ->buildTree() will convert this metadata to actual node classes. Most of the time, you will not have to interact with the config nodes directly, but will delegate this to the Processor class which will call the respective methods on the config node classes.
2011-02-04 13:37:01 +00:00
protected function finalizeValue($value)
{
if (false === $value) {
[Config] Component refactoring The Config component API have changed and the extension configuration files must be updated accordingly: 1. Array nodes must enclosed their children definition in ->children() ... ->end() calls: Before: $treeBuilder->root('zend', 'array') ->arrayNode('logger') ->scalarNode('priority')->defaultValue('INFO')->end() ->booleanNode('log_errors')->defaultFalse()->end() ->end(); After: $treeBuilder->root('zend', 'array') ->children() ->arrayNode('logger') ->children() ->scalarNode('priority')->defaultValue('INFO')->end() ->booleanNode('log_errors')->defaultFalse()->end() ->end() ->end() ->end(); 2. The 'builder' method (in NodeBuilder) has been dropped in favor of an 'append' method (in ArrayNodeDefinition) Before: $treeBuilder->root('doctrine', 'array') ->arrayNode('dbal') ->builder($this->getDbalConnectionsNode()) ->end(); After: $treeBuilder->root('doctrine', 'array') ->children() ->arrayNode('dbal') ->append($this->getDbalConnectionsNode()) ->end() ->end(); 3. The root of a TreeBuilder is now an NodeDefinition (and most probably an ArrayNodeDefinition): Before: $root = $treeBuilder->root('doctrine', 'array'); $this->addDbalSection($root); public function addDbalSection(NodeBuilder $node) { ... } After: $root = $treeBuilder->root('doctrine', 'array'); $this->addDbalSection($root); public function addDbalSection(ArrayNodeDefinition $node) { ... } 4. The NodeBuilder API has changed (this is seldom used): Before: $node = new NodeBuilder('connections', 'array'); After: The recommended way is to use a tree builder: $treeBuilder = new TreeBuilder(); $node = $treeBuilder->root('connections', 'array'); An other way would be: $builder = new NodeBuilder(); $node = $builder->node('connections', 'array'); Some notes: - Tree root nodes should most always be array nodes, so this as been made the default: $treeBuilder->root('doctrine', 'array') is equivalent to $treeBuilder->root('doctrine') - There could be more than one ->children() ... ->end() sections. This could help with the readability: $treeBuilder->root('doctrine') ->children() ->scalarNode('default_connection')->end() ->end() ->fixXmlConfig('type') ->children() ->arrayNode('types') .... ->end() ->end()
2011-03-14 17:29:56 +00:00
$msg = sprintf('Unsetting key for path "%s", value: %s', $this->getPath(), json_encode($value));
throw new UnsetKeyException($msg);
[Security/DependencyInjection] adds support for merging security configurations The merging is done in three steps: 1. Normalization: ================= All passed config arrays will be transformed into the same structure regardless of what format they come from. 2. Merging: =========== This is the step when the actual merging is performed. Starting at the root the configs will be passed along the tree until a node has no children, or the merging of sub-paths of the current node has been specifically disabled. Left-Side Right-Side Merge Result ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -nothing- array Right-Side will be taken. scalar scalar Right-Side will be taken. array false Right-Side will be taken if ->canBeUnset() was called on the array node. false array Right-Side will be taken. array array Each value in the array will be passed to the specific child node, or the prototype node (whatever is present). 3. Finalization: ================ The normalized, and merged config will be passed through the config tree to perform final validation on the submitted values, and set default values where this has been requested. You can influence this process in various ways, here is a list with some examples. All of these methods must be called on the node on which they should be applied. * isRequired(): Node must be present in at least one config file. * requiresAtLeastOneElement(): PrototypeNode must have at least one element. * treatNullLike($value): Replaces null with $value during normalization. * treatTrueLike($value): Same as above just for true * treatFalseLike($value): Same as above just for false * defaultValue($value): Sets a default value for this node (only for scalars) * addDefaultsIfNotSet(): Whether to add default values of an array which has not been defined in any configuration file. * disallowNewKeysInSubsequentConfigs(): All keys for this array must be defined in one configuration file, subsequent configurations may only overwrite these. * fixXmlConfig($key, $plural = null): Transforms XML config into same structure as YAML, and PHP configurations. * useAttributeAsKey($name): Defines which XML attribute to use as array key. * cannotBeOverwritten(): Declares a certain sub-path as non-overwritable. All configuration for this path must be defined in the same configuration file. * cannotBeEmpty(): If value is set, it must be non-empty. * canBeUnset(): If array values should be unset if false is specified. Architecture: ============= The configuration consists basically out of two different sets of classes. 1. Builder classes: These classes provide the fluent interface and are used to construct the config tree. 2. Node classes: These classes contain the actual logic for normalization, merging, and finalizing configurations. After you have added all the metadata to your builders, the call to ->buildTree() will convert this metadata to actual node classes. Most of the time, you will not have to interact with the config nodes directly, but will delegate this to the Processor class which will call the respective methods on the config node classes.
2011-02-04 13:37:01 +00:00
}
foreach ($this->children as $name => $child) {
if (!array_key_exists($name, $value)) {
if ($child->isRequired()) {
2011-05-05 18:42:33 +01:00
$msg = sprintf('The child node "%s" at path "%s" must be configured.', $name, $this->getPath());
$ex = new InvalidConfigurationException($msg);
$ex->setPath($this->getPath());
throw $ex;
[Security/DependencyInjection] adds support for merging security configurations The merging is done in three steps: 1. Normalization: ================= All passed config arrays will be transformed into the same structure regardless of what format they come from. 2. Merging: =========== This is the step when the actual merging is performed. Starting at the root the configs will be passed along the tree until a node has no children, or the merging of sub-paths of the current node has been specifically disabled. Left-Side Right-Side Merge Result ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -nothing- array Right-Side will be taken. scalar scalar Right-Side will be taken. array false Right-Side will be taken if ->canBeUnset() was called on the array node. false array Right-Side will be taken. array array Each value in the array will be passed to the specific child node, or the prototype node (whatever is present). 3. Finalization: ================ The normalized, and merged config will be passed through the config tree to perform final validation on the submitted values, and set default values where this has been requested. You can influence this process in various ways, here is a list with some examples. All of these methods must be called on the node on which they should be applied. * isRequired(): Node must be present in at least one config file. * requiresAtLeastOneElement(): PrototypeNode must have at least one element. * treatNullLike($value): Replaces null with $value during normalization. * treatTrueLike($value): Same as above just for true * treatFalseLike($value): Same as above just for false * defaultValue($value): Sets a default value for this node (only for scalars) * addDefaultsIfNotSet(): Whether to add default values of an array which has not been defined in any configuration file. * disallowNewKeysInSubsequentConfigs(): All keys for this array must be defined in one configuration file, subsequent configurations may only overwrite these. * fixXmlConfig($key, $plural = null): Transforms XML config into same structure as YAML, and PHP configurations. * useAttributeAsKey($name): Defines which XML attribute to use as array key. * cannotBeOverwritten(): Declares a certain sub-path as non-overwritable. All configuration for this path must be defined in the same configuration file. * cannotBeEmpty(): If value is set, it must be non-empty. * canBeUnset(): If array values should be unset if false is specified. Architecture: ============= The configuration consists basically out of two different sets of classes. 1. Builder classes: These classes provide the fluent interface and are used to construct the config tree. 2. Node classes: These classes contain the actual logic for normalization, merging, and finalizing configurations. After you have added all the metadata to your builders, the call to ->buildTree() will convert this metadata to actual node classes. Most of the time, you will not have to interact with the config nodes directly, but will delegate this to the Processor class which will call the respective methods on the config node classes.
2011-02-04 13:37:01 +00:00
}
2011-02-27 19:56:29 +00:00
if ($child->hasDefaultValue()) {
[Security/DependencyInjection] adds support for merging security configurations The merging is done in three steps: 1. Normalization: ================= All passed config arrays will be transformed into the same structure regardless of what format they come from. 2. Merging: =========== This is the step when the actual merging is performed. Starting at the root the configs will be passed along the tree until a node has no children, or the merging of sub-paths of the current node has been specifically disabled. Left-Side Right-Side Merge Result ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -nothing- array Right-Side will be taken. scalar scalar Right-Side will be taken. array false Right-Side will be taken if ->canBeUnset() was called on the array node. false array Right-Side will be taken. array array Each value in the array will be passed to the specific child node, or the prototype node (whatever is present). 3. Finalization: ================ The normalized, and merged config will be passed through the config tree to perform final validation on the submitted values, and set default values where this has been requested. You can influence this process in various ways, here is a list with some examples. All of these methods must be called on the node on which they should be applied. * isRequired(): Node must be present in at least one config file. * requiresAtLeastOneElement(): PrototypeNode must have at least one element. * treatNullLike($value): Replaces null with $value during normalization. * treatTrueLike($value): Same as above just for true * treatFalseLike($value): Same as above just for false * defaultValue($value): Sets a default value for this node (only for scalars) * addDefaultsIfNotSet(): Whether to add default values of an array which has not been defined in any configuration file. * disallowNewKeysInSubsequentConfigs(): All keys for this array must be defined in one configuration file, subsequent configurations may only overwrite these. * fixXmlConfig($key, $plural = null): Transforms XML config into same structure as YAML, and PHP configurations. * useAttributeAsKey($name): Defines which XML attribute to use as array key. * cannotBeOverwritten(): Declares a certain sub-path as non-overwritable. All configuration for this path must be defined in the same configuration file. * cannotBeEmpty(): If value is set, it must be non-empty. * canBeUnset(): If array values should be unset if false is specified. Architecture: ============= The configuration consists basically out of two different sets of classes. 1. Builder classes: These classes provide the fluent interface and are used to construct the config tree. 2. Node classes: These classes contain the actual logic for normalization, merging, and finalizing configurations. After you have added all the metadata to your builders, the call to ->buildTree() will convert this metadata to actual node classes. Most of the time, you will not have to interact with the config nodes directly, but will delegate this to the Processor class which will call the respective methods on the config node classes.
2011-02-04 13:37:01 +00:00
$value[$name] = $child->getDefaultValue();
}
continue;
}
try {
$value[$name] = $child->finalize($value[$name]);
} catch (UnsetKeyException $e) {
[Security/DependencyInjection] adds support for merging security configurations The merging is done in three steps: 1. Normalization: ================= All passed config arrays will be transformed into the same structure regardless of what format they come from. 2. Merging: =========== This is the step when the actual merging is performed. Starting at the root the configs will be passed along the tree until a node has no children, or the merging of sub-paths of the current node has been specifically disabled. Left-Side Right-Side Merge Result ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -nothing- array Right-Side will be taken. scalar scalar Right-Side will be taken. array false Right-Side will be taken if ->canBeUnset() was called on the array node. false array Right-Side will be taken. array array Each value in the array will be passed to the specific child node, or the prototype node (whatever is present). 3. Finalization: ================ The normalized, and merged config will be passed through the config tree to perform final validation on the submitted values, and set default values where this has been requested. You can influence this process in various ways, here is a list with some examples. All of these methods must be called on the node on which they should be applied. * isRequired(): Node must be present in at least one config file. * requiresAtLeastOneElement(): PrototypeNode must have at least one element. * treatNullLike($value): Replaces null with $value during normalization. * treatTrueLike($value): Same as above just for true * treatFalseLike($value): Same as above just for false * defaultValue($value): Sets a default value for this node (only for scalars) * addDefaultsIfNotSet(): Whether to add default values of an array which has not been defined in any configuration file. * disallowNewKeysInSubsequentConfigs(): All keys for this array must be defined in one configuration file, subsequent configurations may only overwrite these. * fixXmlConfig($key, $plural = null): Transforms XML config into same structure as YAML, and PHP configurations. * useAttributeAsKey($name): Defines which XML attribute to use as array key. * cannotBeOverwritten(): Declares a certain sub-path as non-overwritable. All configuration for this path must be defined in the same configuration file. * cannotBeEmpty(): If value is set, it must be non-empty. * canBeUnset(): If array values should be unset if false is specified. Architecture: ============= The configuration consists basically out of two different sets of classes. 1. Builder classes: These classes provide the fluent interface and are used to construct the config tree. 2. Node classes: These classes contain the actual logic for normalization, merging, and finalizing configurations. After you have added all the metadata to your builders, the call to ->buildTree() will convert this metadata to actual node classes. Most of the time, you will not have to interact with the config nodes directly, but will delegate this to the Processor class which will call the respective methods on the config node classes.
2011-02-04 13:37:01 +00:00
unset($value[$name]);
}
}
return $value;
}
2011-02-13 18:06:41 +00:00
/**
* Validates the type of the value.
*
* @param mixed $value
2011-12-13 07:50:54 +00:00
*
2011-02-13 18:06:41 +00:00
* @throws InvalidTypeException
*/
protected function validateType($value)
{
[Security/DependencyInjection] adds support for merging security configurations The merging is done in three steps: 1. Normalization: ================= All passed config arrays will be transformed into the same structure regardless of what format they come from. 2. Merging: =========== This is the step when the actual merging is performed. Starting at the root the configs will be passed along the tree until a node has no children, or the merging of sub-paths of the current node has been specifically disabled. Left-Side Right-Side Merge Result ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -nothing- array Right-Side will be taken. scalar scalar Right-Side will be taken. array false Right-Side will be taken if ->canBeUnset() was called on the array node. false array Right-Side will be taken. array array Each value in the array will be passed to the specific child node, or the prototype node (whatever is present). 3. Finalization: ================ The normalized, and merged config will be passed through the config tree to perform final validation on the submitted values, and set default values where this has been requested. You can influence this process in various ways, here is a list with some examples. All of these methods must be called on the node on which they should be applied. * isRequired(): Node must be present in at least one config file. * requiresAtLeastOneElement(): PrototypeNode must have at least one element. * treatNullLike($value): Replaces null with $value during normalization. * treatTrueLike($value): Same as above just for true * treatFalseLike($value): Same as above just for false * defaultValue($value): Sets a default value for this node (only for scalars) * addDefaultsIfNotSet(): Whether to add default values of an array which has not been defined in any configuration file. * disallowNewKeysInSubsequentConfigs(): All keys for this array must be defined in one configuration file, subsequent configurations may only overwrite these. * fixXmlConfig($key, $plural = null): Transforms XML config into same structure as YAML, and PHP configurations. * useAttributeAsKey($name): Defines which XML attribute to use as array key. * cannotBeOverwritten(): Declares a certain sub-path as non-overwritable. All configuration for this path must be defined in the same configuration file. * cannotBeEmpty(): If value is set, it must be non-empty. * canBeUnset(): If array values should be unset if false is specified. Architecture: ============= The configuration consists basically out of two different sets of classes. 1. Builder classes: These classes provide the fluent interface and are used to construct the config tree. 2. Node classes: These classes contain the actual logic for normalization, merging, and finalizing configurations. After you have added all the metadata to your builders, the call to ->buildTree() will convert this metadata to actual node classes. Most of the time, you will not have to interact with the config nodes directly, but will delegate this to the Processor class which will call the respective methods on the config node classes.
2011-02-04 13:37:01 +00:00
if (!is_array($value) && (!$this->allowFalse || false !== $value)) {
2011-05-05 18:42:33 +01:00
$ex = new InvalidTypeException(sprintf(
'Invalid type for path "%s". Expected array, but got %s',
$this->getPath(),
[Config] Component refactoring The Config component API have changed and the extension configuration files must be updated accordingly: 1. Array nodes must enclosed their children definition in ->children() ... ->end() calls: Before: $treeBuilder->root('zend', 'array') ->arrayNode('logger') ->scalarNode('priority')->defaultValue('INFO')->end() ->booleanNode('log_errors')->defaultFalse()->end() ->end(); After: $treeBuilder->root('zend', 'array') ->children() ->arrayNode('logger') ->children() ->scalarNode('priority')->defaultValue('INFO')->end() ->booleanNode('log_errors')->defaultFalse()->end() ->end() ->end() ->end(); 2. The 'builder' method (in NodeBuilder) has been dropped in favor of an 'append' method (in ArrayNodeDefinition) Before: $treeBuilder->root('doctrine', 'array') ->arrayNode('dbal') ->builder($this->getDbalConnectionsNode()) ->end(); After: $treeBuilder->root('doctrine', 'array') ->children() ->arrayNode('dbal') ->append($this->getDbalConnectionsNode()) ->end() ->end(); 3. The root of a TreeBuilder is now an NodeDefinition (and most probably an ArrayNodeDefinition): Before: $root = $treeBuilder->root('doctrine', 'array'); $this->addDbalSection($root); public function addDbalSection(NodeBuilder $node) { ... } After: $root = $treeBuilder->root('doctrine', 'array'); $this->addDbalSection($root); public function addDbalSection(ArrayNodeDefinition $node) { ... } 4. The NodeBuilder API has changed (this is seldom used): Before: $node = new NodeBuilder('connections', 'array'); After: The recommended way is to use a tree builder: $treeBuilder = new TreeBuilder(); $node = $treeBuilder->root('connections', 'array'); An other way would be: $builder = new NodeBuilder(); $node = $builder->node('connections', 'array'); Some notes: - Tree root nodes should most always be array nodes, so this as been made the default: $treeBuilder->root('doctrine', 'array') is equivalent to $treeBuilder->root('doctrine') - There could be more than one ->children() ... ->end() sections. This could help with the readability: $treeBuilder->root('doctrine') ->children() ->scalarNode('default_connection')->end() ->end() ->fixXmlConfig('type') ->children() ->arrayNode('types') .... ->end() ->end()
2011-03-14 17:29:56 +00:00
gettype($value)
));
2011-05-05 18:42:33 +01:00
$ex->setPath($this->getPath());
throw $ex;
}
}
2011-02-13 18:06:41 +00:00
/**
* Normalizes the value.
2011-02-13 18:06:41 +00:00
*
* @param mixed $value The value to normalize
2011-12-13 07:50:54 +00:00
*
* @return mixed The normalized value
*
* @throws InvalidConfigurationException
2011-02-13 18:06:41 +00:00
*/
protected function normalizeValue($value)
{
[Security/DependencyInjection] adds support for merging security configurations The merging is done in three steps: 1. Normalization: ================= All passed config arrays will be transformed into the same structure regardless of what format they come from. 2. Merging: =========== This is the step when the actual merging is performed. Starting at the root the configs will be passed along the tree until a node has no children, or the merging of sub-paths of the current node has been specifically disabled. Left-Side Right-Side Merge Result ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -nothing- array Right-Side will be taken. scalar scalar Right-Side will be taken. array false Right-Side will be taken if ->canBeUnset() was called on the array node. false array Right-Side will be taken. array array Each value in the array will be passed to the specific child node, or the prototype node (whatever is present). 3. Finalization: ================ The normalized, and merged config will be passed through the config tree to perform final validation on the submitted values, and set default values where this has been requested. You can influence this process in various ways, here is a list with some examples. All of these methods must be called on the node on which they should be applied. * isRequired(): Node must be present in at least one config file. * requiresAtLeastOneElement(): PrototypeNode must have at least one element. * treatNullLike($value): Replaces null with $value during normalization. * treatTrueLike($value): Same as above just for true * treatFalseLike($value): Same as above just for false * defaultValue($value): Sets a default value for this node (only for scalars) * addDefaultsIfNotSet(): Whether to add default values of an array which has not been defined in any configuration file. * disallowNewKeysInSubsequentConfigs(): All keys for this array must be defined in one configuration file, subsequent configurations may only overwrite these. * fixXmlConfig($key, $plural = null): Transforms XML config into same structure as YAML, and PHP configurations. * useAttributeAsKey($name): Defines which XML attribute to use as array key. * cannotBeOverwritten(): Declares a certain sub-path as non-overwritable. All configuration for this path must be defined in the same configuration file. * cannotBeEmpty(): If value is set, it must be non-empty. * canBeUnset(): If array values should be unset if false is specified. Architecture: ============= The configuration consists basically out of two different sets of classes. 1. Builder classes: These classes provide the fluent interface and are used to construct the config tree. 2. Node classes: These classes contain the actual logic for normalization, merging, and finalizing configurations. After you have added all the metadata to your builders, the call to ->buildTree() will convert this metadata to actual node classes. Most of the time, you will not have to interact with the config nodes directly, but will delegate this to the Processor class which will call the respective methods on the config node classes.
2011-02-04 13:37:01 +00:00
if (false === $value) {
return $value;
}
[Config] Component refactoring The Config component API have changed and the extension configuration files must be updated accordingly: 1. Array nodes must enclosed their children definition in ->children() ... ->end() calls: Before: $treeBuilder->root('zend', 'array') ->arrayNode('logger') ->scalarNode('priority')->defaultValue('INFO')->end() ->booleanNode('log_errors')->defaultFalse()->end() ->end(); After: $treeBuilder->root('zend', 'array') ->children() ->arrayNode('logger') ->children() ->scalarNode('priority')->defaultValue('INFO')->end() ->booleanNode('log_errors')->defaultFalse()->end() ->end() ->end() ->end(); 2. The 'builder' method (in NodeBuilder) has been dropped in favor of an 'append' method (in ArrayNodeDefinition) Before: $treeBuilder->root('doctrine', 'array') ->arrayNode('dbal') ->builder($this->getDbalConnectionsNode()) ->end(); After: $treeBuilder->root('doctrine', 'array') ->children() ->arrayNode('dbal') ->append($this->getDbalConnectionsNode()) ->end() ->end(); 3. The root of a TreeBuilder is now an NodeDefinition (and most probably an ArrayNodeDefinition): Before: $root = $treeBuilder->root('doctrine', 'array'); $this->addDbalSection($root); public function addDbalSection(NodeBuilder $node) { ... } After: $root = $treeBuilder->root('doctrine', 'array'); $this->addDbalSection($root); public function addDbalSection(ArrayNodeDefinition $node) { ... } 4. The NodeBuilder API has changed (this is seldom used): Before: $node = new NodeBuilder('connections', 'array'); After: The recommended way is to use a tree builder: $treeBuilder = new TreeBuilder(); $node = $treeBuilder->root('connections', 'array'); An other way would be: $builder = new NodeBuilder(); $node = $builder->node('connections', 'array'); Some notes: - Tree root nodes should most always be array nodes, so this as been made the default: $treeBuilder->root('doctrine', 'array') is equivalent to $treeBuilder->root('doctrine') - There could be more than one ->children() ... ->end() sections. This could help with the readability: $treeBuilder->root('doctrine') ->children() ->scalarNode('default_connection')->end() ->end() ->fixXmlConfig('type') ->children() ->arrayNode('types') .... ->end() ->end()
2011-03-14 17:29:56 +00:00
$value = $this->remapXml($value);
$normalized = array();
foreach ($value as $name => $val) {
if (isset($this->children[$name])) {
$normalized[$name] = $this->children[$name]->normalize($val);
[Config] Component refactoring The Config component API have changed and the extension configuration files must be updated accordingly: 1. Array nodes must enclosed their children definition in ->children() ... ->end() calls: Before: $treeBuilder->root('zend', 'array') ->arrayNode('logger') ->scalarNode('priority')->defaultValue('INFO')->end() ->booleanNode('log_errors')->defaultFalse()->end() ->end(); After: $treeBuilder->root('zend', 'array') ->children() ->arrayNode('logger') ->children() ->scalarNode('priority')->defaultValue('INFO')->end() ->booleanNode('log_errors')->defaultFalse()->end() ->end() ->end() ->end(); 2. The 'builder' method (in NodeBuilder) has been dropped in favor of an 'append' method (in ArrayNodeDefinition) Before: $treeBuilder->root('doctrine', 'array') ->arrayNode('dbal') ->builder($this->getDbalConnectionsNode()) ->end(); After: $treeBuilder->root('doctrine', 'array') ->children() ->arrayNode('dbal') ->append($this->getDbalConnectionsNode()) ->end() ->end(); 3. The root of a TreeBuilder is now an NodeDefinition (and most probably an ArrayNodeDefinition): Before: $root = $treeBuilder->root('doctrine', 'array'); $this->addDbalSection($root); public function addDbalSection(NodeBuilder $node) { ... } After: $root = $treeBuilder->root('doctrine', 'array'); $this->addDbalSection($root); public function addDbalSection(ArrayNodeDefinition $node) { ... } 4. The NodeBuilder API has changed (this is seldom used): Before: $node = new NodeBuilder('connections', 'array'); After: The recommended way is to use a tree builder: $treeBuilder = new TreeBuilder(); $node = $treeBuilder->root('connections', 'array'); An other way would be: $builder = new NodeBuilder(); $node = $builder->node('connections', 'array'); Some notes: - Tree root nodes should most always be array nodes, so this as been made the default: $treeBuilder->root('doctrine', 'array') is equivalent to $treeBuilder->root('doctrine') - There could be more than one ->children() ... ->end() sections. This could help with the readability: $treeBuilder->root('doctrine') ->children() ->scalarNode('default_connection')->end() ->end() ->fixXmlConfig('type') ->children() ->arrayNode('types') .... ->end() ->end()
2011-03-14 17:29:56 +00:00
unset($value[$name]);
}
}
// if extra fields are present, throw exception
if (count($value) && !$this->ignoreExtraKeys) {
2014-12-20 11:33:01 +00:00
$msg = sprintf('Unrecognized option%s "%s" under "%s"', 1 === count($value) ? '' : 's', implode(', ', array_keys($value)), $this->getPath());
2011-05-05 18:42:33 +01:00
$ex = new InvalidConfigurationException($msg);
$ex->setPath($this->getPath());
2011-05-05 18:42:33 +01:00
throw $ex;
[Config] Component refactoring The Config component API have changed and the extension configuration files must be updated accordingly: 1. Array nodes must enclosed their children definition in ->children() ... ->end() calls: Before: $treeBuilder->root('zend', 'array') ->arrayNode('logger') ->scalarNode('priority')->defaultValue('INFO')->end() ->booleanNode('log_errors')->defaultFalse()->end() ->end(); After: $treeBuilder->root('zend', 'array') ->children() ->arrayNode('logger') ->children() ->scalarNode('priority')->defaultValue('INFO')->end() ->booleanNode('log_errors')->defaultFalse()->end() ->end() ->end() ->end(); 2. The 'builder' method (in NodeBuilder) has been dropped in favor of an 'append' method (in ArrayNodeDefinition) Before: $treeBuilder->root('doctrine', 'array') ->arrayNode('dbal') ->builder($this->getDbalConnectionsNode()) ->end(); After: $treeBuilder->root('doctrine', 'array') ->children() ->arrayNode('dbal') ->append($this->getDbalConnectionsNode()) ->end() ->end(); 3. The root of a TreeBuilder is now an NodeDefinition (and most probably an ArrayNodeDefinition): Before: $root = $treeBuilder->root('doctrine', 'array'); $this->addDbalSection($root); public function addDbalSection(NodeBuilder $node) { ... } After: $root = $treeBuilder->root('doctrine', 'array'); $this->addDbalSection($root); public function addDbalSection(ArrayNodeDefinition $node) { ... } 4. The NodeBuilder API has changed (this is seldom used): Before: $node = new NodeBuilder('connections', 'array'); After: The recommended way is to use a tree builder: $treeBuilder = new TreeBuilder(); $node = $treeBuilder->root('connections', 'array'); An other way would be: $builder = new NodeBuilder(); $node = $builder->node('connections', 'array'); Some notes: - Tree root nodes should most always be array nodes, so this as been made the default: $treeBuilder->root('doctrine', 'array') is equivalent to $treeBuilder->root('doctrine') - There could be more than one ->children() ... ->end() sections. This could help with the readability: $treeBuilder->root('doctrine') ->children() ->scalarNode('default_connection')->end() ->end() ->fixXmlConfig('type') ->children() ->arrayNode('types') .... ->end() ->end()
2011-03-14 17:29:56 +00:00
}
return $normalized;
}
/**
2011-12-13 07:50:54 +00:00
* Remaps multiple singular values to a single plural value.
[Config] Component refactoring The Config component API have changed and the extension configuration files must be updated accordingly: 1. Array nodes must enclosed their children definition in ->children() ... ->end() calls: Before: $treeBuilder->root('zend', 'array') ->arrayNode('logger') ->scalarNode('priority')->defaultValue('INFO')->end() ->booleanNode('log_errors')->defaultFalse()->end() ->end(); After: $treeBuilder->root('zend', 'array') ->children() ->arrayNode('logger') ->children() ->scalarNode('priority')->defaultValue('INFO')->end() ->booleanNode('log_errors')->defaultFalse()->end() ->end() ->end() ->end(); 2. The 'builder' method (in NodeBuilder) has been dropped in favor of an 'append' method (in ArrayNodeDefinition) Before: $treeBuilder->root('doctrine', 'array') ->arrayNode('dbal') ->builder($this->getDbalConnectionsNode()) ->end(); After: $treeBuilder->root('doctrine', 'array') ->children() ->arrayNode('dbal') ->append($this->getDbalConnectionsNode()) ->end() ->end(); 3. The root of a TreeBuilder is now an NodeDefinition (and most probably an ArrayNodeDefinition): Before: $root = $treeBuilder->root('doctrine', 'array'); $this->addDbalSection($root); public function addDbalSection(NodeBuilder $node) { ... } After: $root = $treeBuilder->root('doctrine', 'array'); $this->addDbalSection($root); public function addDbalSection(ArrayNodeDefinition $node) { ... } 4. The NodeBuilder API has changed (this is seldom used): Before: $node = new NodeBuilder('connections', 'array'); After: The recommended way is to use a tree builder: $treeBuilder = new TreeBuilder(); $node = $treeBuilder->root('connections', 'array'); An other way would be: $builder = new NodeBuilder(); $node = $builder->node('connections', 'array'); Some notes: - Tree root nodes should most always be array nodes, so this as been made the default: $treeBuilder->root('doctrine', 'array') is equivalent to $treeBuilder->root('doctrine') - There could be more than one ->children() ... ->end() sections. This could help with the readability: $treeBuilder->root('doctrine') ->children() ->scalarNode('default_connection')->end() ->end() ->fixXmlConfig('type') ->children() ->arrayNode('types') .... ->end() ->end()
2011-03-14 17:29:56 +00:00
*
* @param array $value The source values
2011-12-13 07:50:54 +00:00
*
2011-06-04 16:30:56 +01:00
* @return array The remapped values
[Config] Component refactoring The Config component API have changed and the extension configuration files must be updated accordingly: 1. Array nodes must enclosed their children definition in ->children() ... ->end() calls: Before: $treeBuilder->root('zend', 'array') ->arrayNode('logger') ->scalarNode('priority')->defaultValue('INFO')->end() ->booleanNode('log_errors')->defaultFalse()->end() ->end(); After: $treeBuilder->root('zend', 'array') ->children() ->arrayNode('logger') ->children() ->scalarNode('priority')->defaultValue('INFO')->end() ->booleanNode('log_errors')->defaultFalse()->end() ->end() ->end() ->end(); 2. The 'builder' method (in NodeBuilder) has been dropped in favor of an 'append' method (in ArrayNodeDefinition) Before: $treeBuilder->root('doctrine', 'array') ->arrayNode('dbal') ->builder($this->getDbalConnectionsNode()) ->end(); After: $treeBuilder->root('doctrine', 'array') ->children() ->arrayNode('dbal') ->append($this->getDbalConnectionsNode()) ->end() ->end(); 3. The root of a TreeBuilder is now an NodeDefinition (and most probably an ArrayNodeDefinition): Before: $root = $treeBuilder->root('doctrine', 'array'); $this->addDbalSection($root); public function addDbalSection(NodeBuilder $node) { ... } After: $root = $treeBuilder->root('doctrine', 'array'); $this->addDbalSection($root); public function addDbalSection(ArrayNodeDefinition $node) { ... } 4. The NodeBuilder API has changed (this is seldom used): Before: $node = new NodeBuilder('connections', 'array'); After: The recommended way is to use a tree builder: $treeBuilder = new TreeBuilder(); $node = $treeBuilder->root('connections', 'array'); An other way would be: $builder = new NodeBuilder(); $node = $builder->node('connections', 'array'); Some notes: - Tree root nodes should most always be array nodes, so this as been made the default: $treeBuilder->root('doctrine', 'array') is equivalent to $treeBuilder->root('doctrine') - There could be more than one ->children() ... ->end() sections. This could help with the readability: $treeBuilder->root('doctrine') ->children() ->scalarNode('default_connection')->end() ->end() ->fixXmlConfig('type') ->children() ->arrayNode('types') .... ->end() ->end()
2011-03-14 17:29:56 +00:00
*/
protected function remapXml($value)
{
[Security/DependencyInjection] adds support for merging security configurations The merging is done in three steps: 1. Normalization: ================= All passed config arrays will be transformed into the same structure regardless of what format they come from. 2. Merging: =========== This is the step when the actual merging is performed. Starting at the root the configs will be passed along the tree until a node has no children, or the merging of sub-paths of the current node has been specifically disabled. Left-Side Right-Side Merge Result ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -nothing- array Right-Side will be taken. scalar scalar Right-Side will be taken. array false Right-Side will be taken if ->canBeUnset() was called on the array node. false array Right-Side will be taken. array array Each value in the array will be passed to the specific child node, or the prototype node (whatever is present). 3. Finalization: ================ The normalized, and merged config will be passed through the config tree to perform final validation on the submitted values, and set default values where this has been requested. You can influence this process in various ways, here is a list with some examples. All of these methods must be called on the node on which they should be applied. * isRequired(): Node must be present in at least one config file. * requiresAtLeastOneElement(): PrototypeNode must have at least one element. * treatNullLike($value): Replaces null with $value during normalization. * treatTrueLike($value): Same as above just for true * treatFalseLike($value): Same as above just for false * defaultValue($value): Sets a default value for this node (only for scalars) * addDefaultsIfNotSet(): Whether to add default values of an array which has not been defined in any configuration file. * disallowNewKeysInSubsequentConfigs(): All keys for this array must be defined in one configuration file, subsequent configurations may only overwrite these. * fixXmlConfig($key, $plural = null): Transforms XML config into same structure as YAML, and PHP configurations. * useAttributeAsKey($name): Defines which XML attribute to use as array key. * cannotBeOverwritten(): Declares a certain sub-path as non-overwritable. All configuration for this path must be defined in the same configuration file. * cannotBeEmpty(): If value is set, it must be non-empty. * canBeUnset(): If array values should be unset if false is specified. Architecture: ============= The configuration consists basically out of two different sets of classes. 1. Builder classes: These classes provide the fluent interface and are used to construct the config tree. 2. Node classes: These classes contain the actual logic for normalization, merging, and finalizing configurations. After you have added all the metadata to your builders, the call to ->buildTree() will convert this metadata to actual node classes. Most of the time, you will not have to interact with the config nodes directly, but will delegate this to the Processor class which will call the respective methods on the config node classes.
2011-02-04 13:37:01 +00:00
foreach ($this->xmlRemappings as $transformation) {
list($singular, $plural) = $transformation;
if (!isset($value[$singular])) {
continue;
}
$value[$plural] = Processor::normalizeConfig($value, $singular, $plural);
unset($value[$singular]);
}
[Config] Component refactoring The Config component API have changed and the extension configuration files must be updated accordingly: 1. Array nodes must enclosed their children definition in ->children() ... ->end() calls: Before: $treeBuilder->root('zend', 'array') ->arrayNode('logger') ->scalarNode('priority')->defaultValue('INFO')->end() ->booleanNode('log_errors')->defaultFalse()->end() ->end(); After: $treeBuilder->root('zend', 'array') ->children() ->arrayNode('logger') ->children() ->scalarNode('priority')->defaultValue('INFO')->end() ->booleanNode('log_errors')->defaultFalse()->end() ->end() ->end() ->end(); 2. The 'builder' method (in NodeBuilder) has been dropped in favor of an 'append' method (in ArrayNodeDefinition) Before: $treeBuilder->root('doctrine', 'array') ->arrayNode('dbal') ->builder($this->getDbalConnectionsNode()) ->end(); After: $treeBuilder->root('doctrine', 'array') ->children() ->arrayNode('dbal') ->append($this->getDbalConnectionsNode()) ->end() ->end(); 3. The root of a TreeBuilder is now an NodeDefinition (and most probably an ArrayNodeDefinition): Before: $root = $treeBuilder->root('doctrine', 'array'); $this->addDbalSection($root); public function addDbalSection(NodeBuilder $node) { ... } After: $root = $treeBuilder->root('doctrine', 'array'); $this->addDbalSection($root); public function addDbalSection(ArrayNodeDefinition $node) { ... } 4. The NodeBuilder API has changed (this is seldom used): Before: $node = new NodeBuilder('connections', 'array'); After: The recommended way is to use a tree builder: $treeBuilder = new TreeBuilder(); $node = $treeBuilder->root('connections', 'array'); An other way would be: $builder = new NodeBuilder(); $node = $builder->node('connections', 'array'); Some notes: - Tree root nodes should most always be array nodes, so this as been made the default: $treeBuilder->root('doctrine', 'array') is equivalent to $treeBuilder->root('doctrine') - There could be more than one ->children() ... ->end() sections. This could help with the readability: $treeBuilder->root('doctrine') ->children() ->scalarNode('default_connection')->end() ->end() ->fixXmlConfig('type') ->children() ->arrayNode('types') .... ->end() ->end()
2011-03-14 17:29:56 +00:00
return $value;
}
[Security/DependencyInjection] adds support for merging security configurations The merging is done in three steps: 1. Normalization: ================= All passed config arrays will be transformed into the same structure regardless of what format they come from. 2. Merging: =========== This is the step when the actual merging is performed. Starting at the root the configs will be passed along the tree until a node has no children, or the merging of sub-paths of the current node has been specifically disabled. Left-Side Right-Side Merge Result ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -nothing- array Right-Side will be taken. scalar scalar Right-Side will be taken. array false Right-Side will be taken if ->canBeUnset() was called on the array node. false array Right-Side will be taken. array array Each value in the array will be passed to the specific child node, or the prototype node (whatever is present). 3. Finalization: ================ The normalized, and merged config will be passed through the config tree to perform final validation on the submitted values, and set default values where this has been requested. You can influence this process in various ways, here is a list with some examples. All of these methods must be called on the node on which they should be applied. * isRequired(): Node must be present in at least one config file. * requiresAtLeastOneElement(): PrototypeNode must have at least one element. * treatNullLike($value): Replaces null with $value during normalization. * treatTrueLike($value): Same as above just for true * treatFalseLike($value): Same as above just for false * defaultValue($value): Sets a default value for this node (only for scalars) * addDefaultsIfNotSet(): Whether to add default values of an array which has not been defined in any configuration file. * disallowNewKeysInSubsequentConfigs(): All keys for this array must be defined in one configuration file, subsequent configurations may only overwrite these. * fixXmlConfig($key, $plural = null): Transforms XML config into same structure as YAML, and PHP configurations. * useAttributeAsKey($name): Defines which XML attribute to use as array key. * cannotBeOverwritten(): Declares a certain sub-path as non-overwritable. All configuration for this path must be defined in the same configuration file. * cannotBeEmpty(): If value is set, it must be non-empty. * canBeUnset(): If array values should be unset if false is specified. Architecture: ============= The configuration consists basically out of two different sets of classes. 1. Builder classes: These classes provide the fluent interface and are used to construct the config tree. 2. Node classes: These classes contain the actual logic for normalization, merging, and finalizing configurations. After you have added all the metadata to your builders, the call to ->buildTree() will convert this metadata to actual node classes. Most of the time, you will not have to interact with the config nodes directly, but will delegate this to the Processor class which will call the respective methods on the config node classes.
2011-02-04 13:37:01 +00:00
2011-02-13 18:06:41 +00:00
/**
* Merges values together.
*
2012-05-15 21:19:31 +01:00
* @param mixed $leftSide The left side to merge.
2011-02-13 18:06:41 +00:00
* @param mixed $rightSide The right side to merge.
2011-12-13 07:50:54 +00:00
*
2011-02-13 18:06:41 +00:00
* @return mixed The merged values
2011-12-13 07:50:54 +00:00
*
2011-02-13 18:06:41 +00:00
* @throws InvalidConfigurationException
* @throws \RuntimeException
*/
[Security/DependencyInjection] adds support for merging security configurations The merging is done in three steps: 1. Normalization: ================= All passed config arrays will be transformed into the same structure regardless of what format they come from. 2. Merging: =========== This is the step when the actual merging is performed. Starting at the root the configs will be passed along the tree until a node has no children, or the merging of sub-paths of the current node has been specifically disabled. Left-Side Right-Side Merge Result ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -nothing- array Right-Side will be taken. scalar scalar Right-Side will be taken. array false Right-Side will be taken if ->canBeUnset() was called on the array node. false array Right-Side will be taken. array array Each value in the array will be passed to the specific child node, or the prototype node (whatever is present). 3. Finalization: ================ The normalized, and merged config will be passed through the config tree to perform final validation on the submitted values, and set default values where this has been requested. You can influence this process in various ways, here is a list with some examples. All of these methods must be called on the node on which they should be applied. * isRequired(): Node must be present in at least one config file. * requiresAtLeastOneElement(): PrototypeNode must have at least one element. * treatNullLike($value): Replaces null with $value during normalization. * treatTrueLike($value): Same as above just for true * treatFalseLike($value): Same as above just for false * defaultValue($value): Sets a default value for this node (only for scalars) * addDefaultsIfNotSet(): Whether to add default values of an array which has not been defined in any configuration file. * disallowNewKeysInSubsequentConfigs(): All keys for this array must be defined in one configuration file, subsequent configurations may only overwrite these. * fixXmlConfig($key, $plural = null): Transforms XML config into same structure as YAML, and PHP configurations. * useAttributeAsKey($name): Defines which XML attribute to use as array key. * cannotBeOverwritten(): Declares a certain sub-path as non-overwritable. All configuration for this path must be defined in the same configuration file. * cannotBeEmpty(): If value is set, it must be non-empty. * canBeUnset(): If array values should be unset if false is specified. Architecture: ============= The configuration consists basically out of two different sets of classes. 1. Builder classes: These classes provide the fluent interface and are used to construct the config tree. 2. Node classes: These classes contain the actual logic for normalization, merging, and finalizing configurations. After you have added all the metadata to your builders, the call to ->buildTree() will convert this metadata to actual node classes. Most of the time, you will not have to interact with the config nodes directly, but will delegate this to the Processor class which will call the respective methods on the config node classes.
2011-02-04 13:37:01 +00:00
protected function mergeValues($leftSide, $rightSide)
{
if (false === $rightSide) {
// if this is still false after the last config has been merged the
// finalization pass will take care of removing this key entirely
return false;
}
if (false === $leftSide || !$this->performDeepMerging) {
return $rightSide;
}
foreach ($rightSide as $k => $v) {
// no conflict
if (!array_key_exists($k, $leftSide)) {
if (!$this->allowNewKeys) {
2011-05-05 18:42:33 +01:00
$ex = new InvalidConfigurationException(sprintf(
[Security/DependencyInjection] adds support for merging security configurations The merging is done in three steps: 1. Normalization: ================= All passed config arrays will be transformed into the same structure regardless of what format they come from. 2. Merging: =========== This is the step when the actual merging is performed. Starting at the root the configs will be passed along the tree until a node has no children, or the merging of sub-paths of the current node has been specifically disabled. Left-Side Right-Side Merge Result ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -nothing- array Right-Side will be taken. scalar scalar Right-Side will be taken. array false Right-Side will be taken if ->canBeUnset() was called on the array node. false array Right-Side will be taken. array array Each value in the array will be passed to the specific child node, or the prototype node (whatever is present). 3. Finalization: ================ The normalized, and merged config will be passed through the config tree to perform final validation on the submitted values, and set default values where this has been requested. You can influence this process in various ways, here is a list with some examples. All of these methods must be called on the node on which they should be applied. * isRequired(): Node must be present in at least one config file. * requiresAtLeastOneElement(): PrototypeNode must have at least one element. * treatNullLike($value): Replaces null with $value during normalization. * treatTrueLike($value): Same as above just for true * treatFalseLike($value): Same as above just for false * defaultValue($value): Sets a default value for this node (only for scalars) * addDefaultsIfNotSet(): Whether to add default values of an array which has not been defined in any configuration file. * disallowNewKeysInSubsequentConfigs(): All keys for this array must be defined in one configuration file, subsequent configurations may only overwrite these. * fixXmlConfig($key, $plural = null): Transforms XML config into same structure as YAML, and PHP configurations. * useAttributeAsKey($name): Defines which XML attribute to use as array key. * cannotBeOverwritten(): Declares a certain sub-path as non-overwritable. All configuration for this path must be defined in the same configuration file. * cannotBeEmpty(): If value is set, it must be non-empty. * canBeUnset(): If array values should be unset if false is specified. Architecture: ============= The configuration consists basically out of two different sets of classes. 1. Builder classes: These classes provide the fluent interface and are used to construct the config tree. 2. Node classes: These classes contain the actual logic for normalization, merging, and finalizing configurations. After you have added all the metadata to your builders, the call to ->buildTree() will convert this metadata to actual node classes. Most of the time, you will not have to interact with the config nodes directly, but will delegate this to the Processor class which will call the respective methods on the config node classes.
2011-02-04 13:37:01 +00:00
'You are not allowed to define new elements for path "%s". '
.'Please define all elements for this path in one config file. '
.'If you are trying to overwrite an element, make sure you redefine it '
.'with the same name.',
[Security/DependencyInjection] adds support for merging security configurations The merging is done in three steps: 1. Normalization: ================= All passed config arrays will be transformed into the same structure regardless of what format they come from. 2. Merging: =========== This is the step when the actual merging is performed. Starting at the root the configs will be passed along the tree until a node has no children, or the merging of sub-paths of the current node has been specifically disabled. Left-Side Right-Side Merge Result ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -nothing- array Right-Side will be taken. scalar scalar Right-Side will be taken. array false Right-Side will be taken if ->canBeUnset() was called on the array node. false array Right-Side will be taken. array array Each value in the array will be passed to the specific child node, or the prototype node (whatever is present). 3. Finalization: ================ The normalized, and merged config will be passed through the config tree to perform final validation on the submitted values, and set default values where this has been requested. You can influence this process in various ways, here is a list with some examples. All of these methods must be called on the node on which they should be applied. * isRequired(): Node must be present in at least one config file. * requiresAtLeastOneElement(): PrototypeNode must have at least one element. * treatNullLike($value): Replaces null with $value during normalization. * treatTrueLike($value): Same as above just for true * treatFalseLike($value): Same as above just for false * defaultValue($value): Sets a default value for this node (only for scalars) * addDefaultsIfNotSet(): Whether to add default values of an array which has not been defined in any configuration file. * disallowNewKeysInSubsequentConfigs(): All keys for this array must be defined in one configuration file, subsequent configurations may only overwrite these. * fixXmlConfig($key, $plural = null): Transforms XML config into same structure as YAML, and PHP configurations. * useAttributeAsKey($name): Defines which XML attribute to use as array key. * cannotBeOverwritten(): Declares a certain sub-path as non-overwritable. All configuration for this path must be defined in the same configuration file. * cannotBeEmpty(): If value is set, it must be non-empty. * canBeUnset(): If array values should be unset if false is specified. Architecture: ============= The configuration consists basically out of two different sets of classes. 1. Builder classes: These classes provide the fluent interface and are used to construct the config tree. 2. Node classes: These classes contain the actual logic for normalization, merging, and finalizing configurations. After you have added all the metadata to your builders, the call to ->buildTree() will convert this metadata to actual node classes. Most of the time, you will not have to interact with the config nodes directly, but will delegate this to the Processor class which will call the respective methods on the config node classes.
2011-02-04 13:37:01 +00:00
$this->getPath()
));
2011-05-05 18:42:33 +01:00
$ex->setPath($this->getPath());
throw $ex;
[Security/DependencyInjection] adds support for merging security configurations The merging is done in three steps: 1. Normalization: ================= All passed config arrays will be transformed into the same structure regardless of what format they come from. 2. Merging: =========== This is the step when the actual merging is performed. Starting at the root the configs will be passed along the tree until a node has no children, or the merging of sub-paths of the current node has been specifically disabled. Left-Side Right-Side Merge Result ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -nothing- array Right-Side will be taken. scalar scalar Right-Side will be taken. array false Right-Side will be taken if ->canBeUnset() was called on the array node. false array Right-Side will be taken. array array Each value in the array will be passed to the specific child node, or the prototype node (whatever is present). 3. Finalization: ================ The normalized, and merged config will be passed through the config tree to perform final validation on the submitted values, and set default values where this has been requested. You can influence this process in various ways, here is a list with some examples. All of these methods must be called on the node on which they should be applied. * isRequired(): Node must be present in at least one config file. * requiresAtLeastOneElement(): PrototypeNode must have at least one element. * treatNullLike($value): Replaces null with $value during normalization. * treatTrueLike($value): Same as above just for true * treatFalseLike($value): Same as above just for false * defaultValue($value): Sets a default value for this node (only for scalars) * addDefaultsIfNotSet(): Whether to add default values of an array which has not been defined in any configuration file. * disallowNewKeysInSubsequentConfigs(): All keys for this array must be defined in one configuration file, subsequent configurations may only overwrite these. * fixXmlConfig($key, $plural = null): Transforms XML config into same structure as YAML, and PHP configurations. * useAttributeAsKey($name): Defines which XML attribute to use as array key. * cannotBeOverwritten(): Declares a certain sub-path as non-overwritable. All configuration for this path must be defined in the same configuration file. * cannotBeEmpty(): If value is set, it must be non-empty. * canBeUnset(): If array values should be unset if false is specified. Architecture: ============= The configuration consists basically out of two different sets of classes. 1. Builder classes: These classes provide the fluent interface and are used to construct the config tree. 2. Node classes: These classes contain the actual logic for normalization, merging, and finalizing configurations. After you have added all the metadata to your builders, the call to ->buildTree() will convert this metadata to actual node classes. Most of the time, you will not have to interact with the config nodes directly, but will delegate this to the Processor class which will call the respective methods on the config node classes.
2011-02-04 13:37:01 +00:00
}
$leftSide[$k] = $v;
continue;
}
[Config] Component refactoring The Config component API have changed and the extension configuration files must be updated accordingly: 1. Array nodes must enclosed their children definition in ->children() ... ->end() calls: Before: $treeBuilder->root('zend', 'array') ->arrayNode('logger') ->scalarNode('priority')->defaultValue('INFO')->end() ->booleanNode('log_errors')->defaultFalse()->end() ->end(); After: $treeBuilder->root('zend', 'array') ->children() ->arrayNode('logger') ->children() ->scalarNode('priority')->defaultValue('INFO')->end() ->booleanNode('log_errors')->defaultFalse()->end() ->end() ->end() ->end(); 2. The 'builder' method (in NodeBuilder) has been dropped in favor of an 'append' method (in ArrayNodeDefinition) Before: $treeBuilder->root('doctrine', 'array') ->arrayNode('dbal') ->builder($this->getDbalConnectionsNode()) ->end(); After: $treeBuilder->root('doctrine', 'array') ->children() ->arrayNode('dbal') ->append($this->getDbalConnectionsNode()) ->end() ->end(); 3. The root of a TreeBuilder is now an NodeDefinition (and most probably an ArrayNodeDefinition): Before: $root = $treeBuilder->root('doctrine', 'array'); $this->addDbalSection($root); public function addDbalSection(NodeBuilder $node) { ... } After: $root = $treeBuilder->root('doctrine', 'array'); $this->addDbalSection($root); public function addDbalSection(ArrayNodeDefinition $node) { ... } 4. The NodeBuilder API has changed (this is seldom used): Before: $node = new NodeBuilder('connections', 'array'); After: The recommended way is to use a tree builder: $treeBuilder = new TreeBuilder(); $node = $treeBuilder->root('connections', 'array'); An other way would be: $builder = new NodeBuilder(); $node = $builder->node('connections', 'array'); Some notes: - Tree root nodes should most always be array nodes, so this as been made the default: $treeBuilder->root('doctrine', 'array') is equivalent to $treeBuilder->root('doctrine') - There could be more than one ->children() ... ->end() sections. This could help with the readability: $treeBuilder->root('doctrine') ->children() ->scalarNode('default_connection')->end() ->end() ->fixXmlConfig('type') ->children() ->arrayNode('types') .... ->end() ->end()
2011-03-14 17:29:56 +00:00
if (!isset($this->children[$k])) {
throw new \RuntimeException('merge() expects a normalized config array.');
[Security/DependencyInjection] adds support for merging security configurations The merging is done in three steps: 1. Normalization: ================= All passed config arrays will be transformed into the same structure regardless of what format they come from. 2. Merging: =========== This is the step when the actual merging is performed. Starting at the root the configs will be passed along the tree until a node has no children, or the merging of sub-paths of the current node has been specifically disabled. Left-Side Right-Side Merge Result ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -nothing- array Right-Side will be taken. scalar scalar Right-Side will be taken. array false Right-Side will be taken if ->canBeUnset() was called on the array node. false array Right-Side will be taken. array array Each value in the array will be passed to the specific child node, or the prototype node (whatever is present). 3. Finalization: ================ The normalized, and merged config will be passed through the config tree to perform final validation on the submitted values, and set default values where this has been requested. You can influence this process in various ways, here is a list with some examples. All of these methods must be called on the node on which they should be applied. * isRequired(): Node must be present in at least one config file. * requiresAtLeastOneElement(): PrototypeNode must have at least one element. * treatNullLike($value): Replaces null with $value during normalization. * treatTrueLike($value): Same as above just for true * treatFalseLike($value): Same as above just for false * defaultValue($value): Sets a default value for this node (only for scalars) * addDefaultsIfNotSet(): Whether to add default values of an array which has not been defined in any configuration file. * disallowNewKeysInSubsequentConfigs(): All keys for this array must be defined in one configuration file, subsequent configurations may only overwrite these. * fixXmlConfig($key, $plural = null): Transforms XML config into same structure as YAML, and PHP configurations. * useAttributeAsKey($name): Defines which XML attribute to use as array key. * cannotBeOverwritten(): Declares a certain sub-path as non-overwritable. All configuration for this path must be defined in the same configuration file. * cannotBeEmpty(): If value is set, it must be non-empty. * canBeUnset(): If array values should be unset if false is specified. Architecture: ============= The configuration consists basically out of two different sets of classes. 1. Builder classes: These classes provide the fluent interface and are used to construct the config tree. 2. Node classes: These classes contain the actual logic for normalization, merging, and finalizing configurations. After you have added all the metadata to your builders, the call to ->buildTree() will convert this metadata to actual node classes. Most of the time, you will not have to interact with the config nodes directly, but will delegate this to the Processor class which will call the respective methods on the config node classes.
2011-02-04 13:37:01 +00:00
}
[Config] Component refactoring The Config component API have changed and the extension configuration files must be updated accordingly: 1. Array nodes must enclosed their children definition in ->children() ... ->end() calls: Before: $treeBuilder->root('zend', 'array') ->arrayNode('logger') ->scalarNode('priority')->defaultValue('INFO')->end() ->booleanNode('log_errors')->defaultFalse()->end() ->end(); After: $treeBuilder->root('zend', 'array') ->children() ->arrayNode('logger') ->children() ->scalarNode('priority')->defaultValue('INFO')->end() ->booleanNode('log_errors')->defaultFalse()->end() ->end() ->end() ->end(); 2. The 'builder' method (in NodeBuilder) has been dropped in favor of an 'append' method (in ArrayNodeDefinition) Before: $treeBuilder->root('doctrine', 'array') ->arrayNode('dbal') ->builder($this->getDbalConnectionsNode()) ->end(); After: $treeBuilder->root('doctrine', 'array') ->children() ->arrayNode('dbal') ->append($this->getDbalConnectionsNode()) ->end() ->end(); 3. The root of a TreeBuilder is now an NodeDefinition (and most probably an ArrayNodeDefinition): Before: $root = $treeBuilder->root('doctrine', 'array'); $this->addDbalSection($root); public function addDbalSection(NodeBuilder $node) { ... } After: $root = $treeBuilder->root('doctrine', 'array'); $this->addDbalSection($root); public function addDbalSection(ArrayNodeDefinition $node) { ... } 4. The NodeBuilder API has changed (this is seldom used): Before: $node = new NodeBuilder('connections', 'array'); After: The recommended way is to use a tree builder: $treeBuilder = new TreeBuilder(); $node = $treeBuilder->root('connections', 'array'); An other way would be: $builder = new NodeBuilder(); $node = $builder->node('connections', 'array'); Some notes: - Tree root nodes should most always be array nodes, so this as been made the default: $treeBuilder->root('doctrine', 'array') is equivalent to $treeBuilder->root('doctrine') - There could be more than one ->children() ... ->end() sections. This could help with the readability: $treeBuilder->root('doctrine') ->children() ->scalarNode('default_connection')->end() ->end() ->fixXmlConfig('type') ->children() ->arrayNode('types') .... ->end() ->end()
2011-03-14 17:29:56 +00:00
$leftSide[$k] = $this->children[$k]->merge($leftSide[$k], $v);
[Security/DependencyInjection] adds support for merging security configurations The merging is done in three steps: 1. Normalization: ================= All passed config arrays will be transformed into the same structure regardless of what format they come from. 2. Merging: =========== This is the step when the actual merging is performed. Starting at the root the configs will be passed along the tree until a node has no children, or the merging of sub-paths of the current node has been specifically disabled. Left-Side Right-Side Merge Result ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -nothing- array Right-Side will be taken. scalar scalar Right-Side will be taken. array false Right-Side will be taken if ->canBeUnset() was called on the array node. false array Right-Side will be taken. array array Each value in the array will be passed to the specific child node, or the prototype node (whatever is present). 3. Finalization: ================ The normalized, and merged config will be passed through the config tree to perform final validation on the submitted values, and set default values where this has been requested. You can influence this process in various ways, here is a list with some examples. All of these methods must be called on the node on which they should be applied. * isRequired(): Node must be present in at least one config file. * requiresAtLeastOneElement(): PrototypeNode must have at least one element. * treatNullLike($value): Replaces null with $value during normalization. * treatTrueLike($value): Same as above just for true * treatFalseLike($value): Same as above just for false * defaultValue($value): Sets a default value for this node (only for scalars) * addDefaultsIfNotSet(): Whether to add default values of an array which has not been defined in any configuration file. * disallowNewKeysInSubsequentConfigs(): All keys for this array must be defined in one configuration file, subsequent configurations may only overwrite these. * fixXmlConfig($key, $plural = null): Transforms XML config into same structure as YAML, and PHP configurations. * useAttributeAsKey($name): Defines which XML attribute to use as array key. * cannotBeOverwritten(): Declares a certain sub-path as non-overwritable. All configuration for this path must be defined in the same configuration file. * cannotBeEmpty(): If value is set, it must be non-empty. * canBeUnset(): If array values should be unset if false is specified. Architecture: ============= The configuration consists basically out of two different sets of classes. 1. Builder classes: These classes provide the fluent interface and are used to construct the config tree. 2. Node classes: These classes contain the actual logic for normalization, merging, and finalizing configurations. After you have added all the metadata to your builders, the call to ->buildTree() will convert this metadata to actual node classes. Most of the time, you will not have to interact with the config nodes directly, but will delegate this to the Processor class which will call the respective methods on the config node classes.
2011-02-04 13:37:01 +00:00
}
return $leftSide;
}
2011-06-08 11:16:48 +01:00
}