One of the central classes in the Symfony framework is:
Symfony\Component\HttpFoundation\Request
The front controller instanciates this object and populates it with the properties of the current HTTP Request. Controllers can easily obtain the current Request instance. Services can have the current Request object injected either directly or via the request stack (which is also subrequest safe).
Some Request properties can be automatically set and used, e.g. if you use the {_locale} parameter in your Route, it’s content will automatically be set on the Request object. If activated, the Translation Component will automatically perform all translations using the locale Parameter of the current Request .
eZ Publish follows this systematic with their ConfigResolver. This is provided as a Symfony style service, so it can easily be obtained in controllers and injected into services of your own like this:
services:
my_service:
class: My\Awesome\Service
arguments: [@ezpublish.config.resolver]
As far as I understand eZ Publish, one eZ Publish instance can host different applications. Settings for each of your applications are identified via the applications own namespace prefix. Each application can be exposed as a number of differet sites. Parameters can be specified (e.g. in your parameters.yml) like this:
parameters:
namespace.scope.parameter.name
In this way the same parameter can be given different values depending on the respective eZ Publish application and site that the current request is being processed for.
Great stuff!