Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Injection Inception, Change #1: Adding EventDispatcher to DI #7954

Merged
merged 6 commits into from May 21, 2015

Conversation

diosmosis
Copy link
Member

As the title states, this PR puts the EventDispatcher singleton into the DI container.

It includes the addition of a new config entry 'observers.global' that allows defining observers before the container is created. This is necessary for test environment setup, since we register event observers before the actual entry scripts create the container. It can also be useful to users who want to augment their Piwik, without actually creating a plugin (they can define observers in config/config.php).

Tests may not pass yet, travis is still having a hard time.

@diosmosis diosmosis added c: Platform For Matomo platform changes that aren't impacting any of our APIs but improve the core itself. not-in-changelog For issues or pull requests that should not be included in our release changelog on matomo.org. Needs Review PRs that need a code review labels May 20, 2015
@diosmosis diosmosis added this to the 2.14.0 milestone May 20, 2015
@mnapoli
Copy link
Contributor

mnapoli commented May 21, 2015

Awesome, really easy to review :D

  • tests seem to be failing on EventManager::unsetInstance() (and maybe other things)
  • I'm wondering wether it's really useful to add observers.global into the container -> in TestingEnvironment can't we first create the container/environment, then add event listeners? Having a deeper look at the events there's probably no choice (because they are events that happen during the init of the application).


$diConfig['observers.global'] = \DI\add($globalObservers);

StaticContainer::addDefinitions($diConfig);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nitpicking: just to make it look more "familiar" for those that aren't with DI config, I would write it like that:

StaticContainer::addDefinitions(array(
    'observers.global' => \DI\add($globalObservers),
));

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

$diConfig is set to provideContainerConfig(), so this would override the entire array (StaticContainer::addDefinitions does not use array_merge()).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

woops yes!

@mnapoli
Copy link
Contributor

mnapoli commented May 21, 2015

I'm 👍 for merge when tests are OK.

By the way we need to keep in mind that StaticContainer::addDefinitions() does an array_merge() IIRC, so adding twice the same entry would overwrite the previous one. This might be a problem here since you add event observers in tests/PHPUnit/proxy/piwik.php and then again in TestingEnvironment -> could the second overwrite the first?

@diosmosis
Copy link
Member Author

Having a deeper look at the events there's probably no choice (because they are events that happen during the init of the application).

It's needed mainly because the proxy scripts don't create the environment themselves, the real entry points do. So we can't change it to our own environment, and must define the event handlers before the environment is created.

Since I added the concept of EnvironmentManipulators in another PR, though, maybe I can re-use that for this. I'm no longer sure which should get merged first now, though :)

By the way we need to keep in mind that StaticContainer::addDefinitions() does an array_merge() IIRC, so adding twice the same entry would overwrite the previous one. This might be a problem here since you add event observers in tests/PHPUnit/proxy/piwik.php and then again in TestingEnvironment -> could the second overwrite the first?

It doesn't do an array_merge(), did you intend it to when making the change? I can include that change here, since most test classes now create Environment instances directly, instead of using StaticContainer methods. (so extra definitions would not pile up if array_merge() was used)

EDIT: Also should note that we pass an array of event handlers in proxy/piwik.php to TestingEnvironment::addHooks(), which we add items to in the aforementioned addHooks(), so nothing should get overwritten.

@diosmosis diosmosis force-pushed the test_env_di_1 branch 3 times, most recently from 45c6415 to c0640d5 Compare May 21, 2015 14:37
diosmosis added 6 commits May 21, 2015 08:32
…llObservers method. This method is only used to 'reset' the EventDispatcher, and is no longer necessary thanks to DI.
…observers, since the container is not created at this point.
…d of calling Piwik::addAction, since the latter needs the DI container (which is not setup yet).
…required since the environment can be modified during tests, and these modifications must be removed after (eg, event observers can be registered). Since Plugin\Manager is in DI, we must also reload plugins.

Integration/Plugin/ManagerTest.php was modified; order of plugins changed because Fixture::loadPlugins() will use TestingEnvironment to gather plugins, which sorts plugins by name.
…d since the Plugin\Manager is provided through DI.
diosmosis added a commit that referenced this pull request May 21, 2015
Adding EventDispatcher to DI, allow defining event handlers in DI so they can be defined before the container is created, make sure to recreate the test environment for integration tests in setUp().
@diosmosis diosmosis merged commit 64f98e3 into master May 21, 2015
@diosmosis diosmosis deleted the test_env_di_1 branch May 21, 2015 22:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
c: Platform For Matomo platform changes that aren't impacting any of our APIs but improve the core itself. Needs Review PRs that need a code review not-in-changelog For issues or pull requests that should not be included in our release changelog on matomo.org.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants