Dynamic configuration¶
ConfigResolver¶
Dynamic configuration is handled by a ConfigResolver.
It exposes the hasParameter()
and getParameter()
methods.
You can use them to check the different scopes available for a given namespace to find the appropriate parameter.
In order to work with the ConfigResolver, your dynamic settings must have the following name format: <namespace>.<scope>.parameter.name
.
1 2 3 4 5 6 7 8 9 10 11 |
|
Inside a controller, in site_group
SiteAccess, you can use the parameters in the following way
(note that the same applies for hasParameter()
):
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
|
Tip
To learn more about scopes, see SiteAccess documentation.
Both getParameter()
and hasParameter()
can take three arguments:
$paramName
- the name of the parameter$namespace
- your application namespace,myapp
in the previous example. If null, the default namespace will be used, which isezsettings
by default.$scope
- a SiteAccess name. If null, the current SiteAccess will be used.
Note
In debug mode, ConfigResolver detects if parameters were loaded prior to initialization of SiteAccess to warn about issues.
It will log all instances of getParameter()
that may be used unsafely.
If a problem occurs, you will receive a warning that ConfigResolver had been used to load parameter languages
before SiteAccess was loaded by services: my.own.service
and ez.service.used.too.early
.
To avoid such issues:
- Avoid eager usage of config resolver (e.g. in service factories).
- Instead of using
ctor('$dynamic_param$')
, use(setter('$dynamic_param$'))
as it allows the system to update your service with changes on scope changes. - Load the parameter lazily by injecting ConfigResolver, and get the parameter from it when you need to instead of during construction.
- Try using lazy commands.
- Try configuring lazy services.
Inject the ConfigResolver in your services¶
Instead of injecting the whole ConfigResolver service, you may directly inject your SiteAccess-aware (dynamic) settings into your own services.
You can use the ConfigResolver in your own services whenever needed.
To do this, inject the ezpublish.config.resolver
service:
1 2 3 4 5 6 7 |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
|
Dynamic settings injection¶
When implementing a service which needs SiteAccess-aware settings (e.g. language settings), you can inject these dynamic settings explicitly from their service definition.
Syntax¶
Static container parameters follow the %<parameter_name>%
syntax in Symfony.
Dynamic parameters have the following: $<parameter_name>[; <namespace>[; <scope>]]$
.
Default namespace is ezsettings
, and default scope is the current SiteAccess.
For more information, see ConfigResolver.
DynamicSettingParser¶
The DynamicSettingParser service can be used for adding support of the dynamic settings syntax.
This service has ezpublish.config.dynamic_setting.parser
for ID and implements eZ\Bundle\EzPublishCoreBundle\DependencyInjection\Configuration\SiteAccessAware\DynamicSettingParserInterface
.
Limitations¶
- It is not possible to use dynamic settings in your semantic configuration (e.g.
config.yml
orezplatform.yml
) as they are meant primarily for parameter injection in services. - It is not possible to define an array of options having dynamic settings. They will not be parsed. Workaround is to use separate arguments/setters.
- Injecting dynamic settings in request listeners is not recommended, as it won't be resolved with the correct scope
(request listeners are instantiated before SiteAccess match).
Workaround is to inject the ConfigResolver instead, and resolve the setting in your
onKernelRequest
method (or equivalent).
Examples¶
Injecting an eZ parameter¶
Defining a simple service needing a languages
parameter (that is, prioritized languages).
Note
Internally, the languages
parameter is defined as ezsettings.<siteaccess_name>.languages
.
ezsettings
is the internal eZ namespace.
Using setter injection (preferred)¶
1 2 3 4 5 6 7 8 |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
|
Caution
Ensure you always add null
as a default value, especially if the argument is type-hinted.
Using constructor injection¶
1 2 3 4 5 6 7 |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
|
Tip
Setter injection for dynamic settings should always be the preferred method. It enables you to update your services that depend on it when ConfigResolver is updating its scope (e.g. when previewing content in a given SiteAccess). However, only one dynamic setting should be injected by setter.
Constructor injection will make your service be reset in that case.
Injecting third party parameters¶
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
|
1 2 3 4 5 6 7 8 9 10 |
|