Status | ||||
---|---|---|---|---|
|
Status | |
---|---|
colour | Yellow |
title | 2014.11 |
Table of Contents |
Description
Before 5.4, if one you wanted to implement a service needing siteaccess-aware settings (e.g. language settings),
they you needed to inject the whole ConfigResolver
(ezpublish.config.resolver
) and get the needed settings from it. This was not neither very convenient nor explicit.
Goal The goal of this feature is to allow developers to inject these dynamic settings explicitly from their service definition (yml, xml, annotation, etc...).
Usage
Syntax
Static container parameters follows follow the %<parameter_name>%
syntax in Symfony.
Dynamic parameters have the following: $<parameter_name>[; <namespace>[; <scope>]]$
, default namespace being ezsettings
,
and default scope being the current siteaccess.
Info |
---|
For more information, see ConfigResolver documentation. |
...
This feature also introduces a DynamicSettingParser service that 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
.
...
- 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 resolving the your setting in your
onKernelRequest
method (or equivalent).
...