issei-m/sf-dependency-injection-plugin

Supporing Symfony's DependencyInjection component for your symfony1 project

Maintainers

👁 issei-m

Package info

github.com/issei-m/sfDependencyInjectionPlugin

Type:symfony1-plugin

pkg:composer/issei-m/sf-dependency-injection-plugin

Statistics

Installs: 11 522

Dependents: 0

Suggesters: 0

Stars: 7

Open Issues: 0

v1.3.1 2015-07-03 09:49 UTC

Suggests

Provides

None

Conflicts

None

Replaces

None

MIT 8d70582efb91bc17f16161c11b5ec38b2c50c716

  • Issei Murasawa <issei.m7.woop@gmail.com>

pluginservicedependency-injectionsymfony1

This package is auto-updated.

Last update: 2026-06-05 13:12:24 UTC


README

👁 Build Status

Provides integration Symfony2's Dependency Injection component with your older symfony (1.4+) project.

Installation

Using Composer would be best way:

$ composer require issei-m/sf-dependency-injection-plugin

Here, Composer would install this plugin in your plugins directory and some other libraries plugin depends on into vendor.

If you don't use Composer, you need to install this plugin and some others manually.

Usage

First, create your services.yml in %SF_ROOT%/config/services.yml. It can be defined your parameters/services to each different environments.

Something like:

# config/services.yml

dev:
 parameters:
 mailer.transport: gmail

all:
 parameters:
 # ...
 mailer.transport: sendmail

 services:
 mailer:
 class: Mailer
 arguments: ["%mailer.transport%"]
 newsletter_manager:
 class: NewsletterManager
 calls:
 - [setMailer, ["@mailer"]]

The services.yml is supporting the configuratoin cascade like the settings.yml, and it can be located in several different config directory for apps (e.g.apps/frontend/config). When the ServiceContainer is compiled, the values from these are merged.

Next, enable this plugin at your ProjectConfiguration:

class ProjectConfiguration extends sfProjectConfiguration
{
 public function setup()
 {
 $this->enablePlugins('sfDependencyInjectionPlugin');
 ...
 }
}

Now, your sfContext has installed Symfony's service container, it is used as following in your code:

// Get the ServiceContainer.
$container = sfContext::getInstance()->getContainer();

// Retrieve the NewsletterManager class which was initialized with the Mailer.
$newsletterManager = $container->get('newsletter_manager');

If you use lexpress/symfony1, sfServiceContainer is replaced with plugin's service container. But it might work almost as well as framework's one:

$container = sfContext::getInstance()->getServiceContainer();
$newsletterManager = sfContext::getInstance()->getService('newsletter_manager');

At task

Even though you don't initialize the sfContext at task, you can initialize the service container manually like this:

$containerClass = require $this->configuration->getConfigCache()->checkConfig('config/services.yml', true);
$container = new $containerClass();

Event

When container is compiled, service_container.build event is fired. You can expand container definitions if you subscribe this event.

It means you can have control your service container as you wish with your own extension, compiler pass etc...:

class ProjectConfiguration extends sfProjectConfiguration
{
 public function setup()
 {
 $this->dispatcher->connect('service_container.build', function (sfEvent $event) {
 /** @var \Symfony\Component\DependencyInjection\ContainerBuilder $container */
 $container = $event->getSubject();
 $container->addObjectResource($this);

 // additional parameter
 $container->setParameter('foo', 'bar');

 // add extension
 $container->registerExtension(new YourExtension());

 // add compiler pass
 $container->addCompilerPass(new YourPass());
 });
 }
}