Download the PHP package inviqa/magento-symfony-container without Composer

magento-symfony-container

Provides Magento with an instance of a Symfony DI Container

Documentation for the Symfony DI Component can be found here.

Upon requesting the container for the first time, the configuration directories are scanned and the container is compiled. The container will be cached in public/var/cache/container.cache.php and subsequently read from there. You can use the admin cache control panel to enable/disable caching for the container, when disabled all service config files will be re-read when they are changed, otherwise they are ignored. To force the cache to refresh you can use n98-magerun or the admin cache-control panel.

Services Configuration

All services configuration files are expected to be found in either the system-wide etc/ directory or within each modules etc/ directory. The expected format is XML, therefore the configuration files are expected to be called "services.xml"

The following is an example of defining a service named "acme.checkout", which, in turn, depends on a Magento catalog model and a mail service. Via the configuration, we can provide "acme.product.catalog" - which is constructed by calling Mage::getModel('inviqa_acme/catalog') - as a dependency to "acme.checkout". Thus our "acme.checkout" service/class is now decoupled from Magento and its logic and business rules can be tested independently.

Your implementation of Inviqa\Acme\Checkout might look something like this:

Along with a Catalog interface

And have your Inviqa_Acme_Model_Catalog implment the Catalog interface.

Usage

The idea behind using a DI container is to be able to easily decouple your code, therefore direct access to the container is bad practice and should be limited to where absolutely necessary for example where a service cannot be provided automatically (e.g. a Magento controller or observer).

Usage via trait

Usage directly via helper

Test Environment

The configuration builder reads the Magento configuration node "global/environment" and uses this to switch the container generator to "test" environment. The string expected in the "global/environment" node is "test". In this mode, the container generator will read additional services_test.xml files, which will override services defined in services.xml if their id's match. In this way, you can use "mock" services for integration testing purposes. (see additional documentation in https://github.com/inviqa/symfony-container-generator)

Providing Magento Store Configuration Values to Service Constructors

If your service requires a value from the store configuration, something which would normally require calling Mage::getStoreConfig('web/secure/base_url') for example, you can use the special tag mage.config in place of an node in your service definition. The "key" attribute is a regular Magento store configuration key. This will simply add the value of requested store configuration to the list of service constructor arguments:

This will result in the constructor of Acme_Service being called with two extra arguments:

If the specified key does not exist, or is empty, the argument will be null or empty.

Explicitly Providing Dependencies via __dependencies (since version 0.5.0)

Certain Magento classes, such as controllers, observers and blocks are instantiated by the system and therefore cannot be instantiated by the DI Container, nevertheless an additional service tag can make it easier to explicitly provide dependencies to these classes. Adding the mage.injectable tag to a service will allow you to provide these service dependencies after the service has been instantiated. The services arguments will be provided to the dependencies method, provided you call ServiceInjector::setupDependencies($class) after service instantiation, and your service has a dependencies method that contains typehints that match the arguments types in order.

For convenience, setupDependencies is called on controllers by hooking into the pre-dispatch event, for other classes such as observers and blocks you will have to call it yourself by overriding the class constructor.

For controllers, a service definition might look like this

And the class itself will implement __dependencies() thus:

Unfortunately your controller will still be coupled to Mage due to extending Mage_Core_Controller_Front_Action, and thus - untestable as a unit, but it will at least be clear what its' dependencies are and they will be type-hinted.

To provide dependencies to other classes after they are instantiated, in addition to using the mage.injectable tag and implementing __dependencies, you will have to override your class' constructor, for example:

Registering your own compiler pass

Create a custom compiler pass class in your project.

Create a Magento observer and configure it to listen to the symfony_container_before_container_generator Magento event. Update this observer to inject the custom compiler pass into the generator config, as shown below: