Excerpt | |||||
---|---|---|---|---|---|
|
Table of Contents |
---|
Status | ||||
---|---|---|---|---|
|
Description
Symfony Config component makes it possible to define semantic configuration, exposed to the end - developer. This configuration is validated by rules you define, e.g. validating type (string, array, integer, boolean, etc...). Usually, once validated and processed, this semantic configuration is then mapped to internal key/value parameters stored in the ServiceContainer
.
eZ Publish Platform uses this for its core configuration, but adds another configuration level, the SiteAccessthe siteaccess. For each defined SiteAccesssiteaccess, we need to be able to use the same configuration tree in order to define SiteAccess siteaccess-specific config. These settings then need to be mapped to SiteAccess siteaccess-aware internal parameters , that one you can retrieve via the ConfigResolver
. For this, internal keys need to follow the format <namespace>.<scope>.<parameter_name>
, namespace
being specific to your app/bundle, scope
being the SiteAccesssiteaccess, SiteAccess siteaccess group, default
or global
, parameter_name
being the actual setting identifier.
Info |
---|
For more information on ConfigResolver, namespaces and scopes, see eZ Publish configuration basics. |
Goal The goal of this feature is to make it easy to implement a SiteAccess a siteaccess-aware semantic configuration and its mapping to internal config for any eZ bundle developer.
...
An abstract Configuration
class has been added, simplifying the way to add a SiteAccess siteaccess settings tree like the following:
...
Code Block | ||
---|---|---|
| ||
namespace Acme\DemoBundle\DependencyInjection; use eZ\Bundle\EzPublishCoreBundle\DependencyInjection\Configuration\SiteAccessAware\Configuration as SiteAccessConfiguration; use Symfony\Component\Config\Definition\Builder\NodeBuilder; use Symfony\Component\Config\Definition\Builder\TreeBuilder; class Configuration extends SiteAccessConfiguration { public function getConfigTreeBuilder() { $treeBuilder = new TreeBuilder(); $rootNode = $treeBuilder->root( 'acme_demo' ); // $systemNode will then be the root of siteaccess aware settings. $systemNode = $this->generateScopeBaseNode( $rootNode ); $systemNode ->scalarNode( 'hello' )->isRequired()->end() ->arrayNode( 'foo_setting' ) ->children() ->scalarNode( "foo" )->end() ->scalarNode( "some" )->end() ->integerNode( "an_integer" )->end() ->booleanNode( "enabled" )->end() ->end() ->end(); return $treeBuilder; } } |
Info |
---|
Default name for the SiteAccess the siteaccess root node is |
...
Semantic configuration must always be mapped to internal key/value settings within the ServiceContainer
. This is usually done in the DIC extension.
For SiteAccess siteaccess-aware settings, new ConfigurationProcessor
and Contextualizer
classes have been introduced to ease the process.
...
Tip | |||||
---|---|---|---|---|---|
| |||||
You can map simple settings by calling
|
Warning | ||||
---|---|---|---|---|
| :||||
Always ensure you have defined and loaded default settings. |
...
When you define a hash as semantic config, you sometimes don't want the SiteAccess siteaccess settings to replace the default or group values, but enrich them by appending new entries. This is made possible by using $processor->mapConfigArray()
, which needs to be called outside the closure (before or after), in order to be called only once.
...
Code Block | ||||
---|---|---|---|---|
| ||||
acme_demo: system: sa_group: foo_setting: foo: bar some: thing an_integer: 123 # Assuming "sa1" is part of "sa_group" sa1: foo_setting: an_integer: 456 enabled: true j_adore: le_saucisson |
What we want here , is that keys defined for foo_setting
are merged between default/group/SiteAccesssiteaccess:
Code Block | ||||
---|---|---|---|---|
| ||||
parameters: acme_demo.sa1.foo_setting: foo: bar some: thing planets: [Earth] an_integer: 456 enabled: true j_adore: le_saucisson |
...
Code Block | ||||
---|---|---|---|---|
| ||||
acme_demo: system: sa_group: foo_setting: foo: bar some: thing planets: [Mars, Venus] an_integer: 123 # Assuming "sa1" is part of "sa_group" sa1: foo_setting: an_integer: 456 enabled: true j_adore: [le_saucisson, la_truite_a_la_vapeur] |
Result of using ContextualizerInterface::MERGE_FROM_SECOND_LEVEL
option:
...
- Semantic setting name and internal name will be the same (like
foo_setting
in the examples above). - Applicable to 1st first level semantic parameter only (i.e. settings right under the SiteAccess siteaccess name).
- Merge is not recursive. Only 2nd second level merge is possible by using
ContextualizerInterface::MERGE_FROM_SECOND_LEVEL
option.
...