Service Container

Service Container is an API module based on ctools to enable a Drupal 7 quick and easy lightweight service container with 100% unit test coverage.

It is very similar in syntax to a Symfony container, but was written from scratch as a Symfony Dependency was not wanted - using some of Drupal 8 Core and Component directly. They will likely depend on a drupal8core project in the future - but for now the copy is fine.

This allows to use an extensible service container (like in Drupal 8) and write modules in Drupal 7 as if they were using Drupal 8.

The main benefit is being able to use unit testing.

service_container uses PHP Unit and travis.yml, but the tests and a composer.json are isolated in the tests/ directory, so no vendor or composer multi map is needed by default.

It was originally written for the render_cache module, but since then others have expressed interest in using it, so this will split it out.

Requirements

• registry_autoload or any other PSR-4 autoloader.

How does it work

There is two ways:

a) Add [module].services.yml like in Drupal 8 and depend on service_container_symfony submodule. => done

b) Register a ServiceContainer/ServiceProvider CTools plugin:

You register your CTools plugins normally and reference service_container, ServiceProvider plugin.

Then you implement:

public function getContainerDefinition() {

like:

http://cgit.drupalcode.org/render_cache/tree/src/RenderCache/ServiceProv...

There is also an altering function that can be seen as the conterpart to a compilerPass in Symfony:

http://cgit.drupalcode.org/render_cache/tree/src/RenderCache/ServiceProv...

Specialties

The container definition is cached, which means it is possible to use the container (when it is in cache) during hook_boot().

The more you avoid procedural code and use the ModuleHandler to invoke other modular code, the better:

a) You can unit test it.
b) You can do things during hook_boot() or even DRUPAL_BOOTSTRAP_CONFIGURATION.

Registering CTools plugins

By default the service\_container supports CTools discovery, to register your plugins all you need to do is:

    $parameters['ctools_plugins_auto_discovery.render_cache'] = array('render_cache');

And you can then get a plugin via:

    $rcc = \Drupal::service('render_cache.controller')->createInstance('block');

Because the plugin managers implement the whole discovery interface, you can get all definitions with ease.

  $plugins = \Drupal::service('render_cache.controller')->getDefinitions();

Your plugin itself looks like:

cat modules/render_cache_block/src/RenderCache/Controller/block.inc

$plugin = array(
  'class' => "\\Drupal\\render_cache_block\\RenderCache\\Controller\\BlockController",
  'arguments' => array('@render_stack', '@render_cache.cache'),
);

So you can use normal container parameter syntax.

Provides the following services

• * module handler ('module_handler') and module installer ('module_installer')
• * service container ('service_container')
• * database ('database')
• * key value store ('keyvalue', 'keyvalue.database')
• * variable, a wrapper for variable_get() / variable_set()
• * A lock ('lock')
• * A wrapper for url() / l() ('url_generator', 'link_generator')
• * Flood, a wrapper for the flood mechanisms
• * Messenger, a wrapper for displaying messages
• * Drupal 7 Legacy, a wrapper for accessing the Drupal 7 legacy functions.
• * More to come...

Differences to Symfony Container?

- Way more light-weight implementation doing only what is necessary for my uses cases.
- Combines the best of the D7 Drupal world (ctools) with advanced caching techniques, therefore no discovery problems.
- API compatible with Symfony DependencyInjection component
- When using service_container_symfony also uses the ContainerBuilder() then dumps that back to PHPArray syntax.

Current limitations / Bugs

- Parameter handling does not work for e.g. class