eZ Community » Blogs » Core Development team » New in eZ 5.4: Dynamic settings...

By

New in eZ 5.4: Dynamic settings injection

Thursday 09 October 2014 2:57:10 pm

  • Currently 3 out of 5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

When developing your project in Symfony stack, you more than likely already implemented services. If you don't already know it, a service is nothing more than a PHP object which purpose is to perform tasks. In MVC terms, they correspond to the M, i.e. the Model. This PHP object is given a label (or service ID) and a configuration for the service container so it can build it for you. In this configuration, you define all your service dependencies, being other services or parameters. This is a rough explanation of what Dependency injection is.

Sometimes though (often maybe), some of your services will need a SiteAccess-aware parameter (e.g. a setting depending on the current SiteAccess), being from eZ configuration or from your own. A good example can be prioritized languages, or the root location ID.

The past and the present

In eZ Publish legacy, we used to use eZINI for this. It resolved settings depending on runtime context, using a Singleton. In Symfony, all parameters are frozen when compiling the ServiceContainer, which then has no notion of runtime context. To workaround this, we introduced in eZ 5 the ConfigResolver which acts in the same way than eZINI, except that we don't use singletons any more :). The main problem with it is that you are forced to inject the ConfigResolver (@ezpublish.config.resolver) in your services, while you usually only need one or two settings

Furthermore, it is recommended to keep the ConfigResolver object as a property in your object and resolve your settings only when you need them. This is because when the runtime context changes (e.g. content preview), it is also changed inside the ConfigResolver, but not for already resolved settings!

The (near) future

To get rid of these issues, we introduced in eZ 5.4 / 2014.11 a new syntax for service configuration. It allows direct injection of dynamic settings in your services, instead of injecting the ConfigResolver. The syntax is $<parameterName>[;<namespace>[;<scope>]]$.

Usage

It is of course also possible to use this syntax with constructor injection. However, setter injection for dynamic settings should always be preferred, as it makes it possible to update your services that depend on them when ConfigResolver is updating its scope (e.g. when previewing content in a given SiteAccess). Constructor injection will make your service be reset in that case.
However, only one dynamic setting should be injected by setter.
 

Using it with custom settings

This works for any dynamic settings available in eZ. And while at it, you may want to have a look at default_settings.yml file in EzPublishCoreBundle to see all available dynamic settings ; they all have the same format: ezsettings.default.<parameterName>. ezsettings being the default namespace used by the ConfigResolver, and default being the default scope.

But this feature is not limited to internal eZ settings, you can also use it for your own custom settings !

 

Icing on the cake: Assetic integration

Assetic is a really nice tool, but it sometimes generates frustration as it's not as flexible as you expect to. This is the case when it comes to using javascripts and stylesheets Twig tags. It is indeed not possible to use Twig variables to add JS/CSS files.

As of eZ 5.4 / 2014.11, it is possible to use the new dynamic setting syntax here:

 

Resources

 

Enjoy ! :)

Proudly Developed with from