Skip to content

Feature/eventmanager di usability #944

Merged
merged 6 commits into from Apr 20, 2012

3 participants

@weierophinney
Zend Framework member

Shared Collections support for EventManager

This is a solution for usage of the StaticEventManager. Basically, it
will instead expect the following:

  • Classes composing an EventManager will implement EventManagerAware, and thus opt-in to setter injection of an EM instance
    • EM instances will not be shared between classes
  • The EM implements the SharedEventManagerAware interface, indicating it opts-in to setter injection of a SharedEventManager (note: not static)
    • A single "SharedEventManager" will be shared between all instances of EventManager

This commit does the following:

  • Renames StaticEventCollection to SharedEventCollection
  • Creates SharedEventManager, which implements all the functionality of StaticEventManager except the singleton aspects.
  • StaticEventManager now extends SharedEventManager, and simply implements a singleton pattern.
  • Introduced EventManagerAware and SharedEventManagerAware interfaces; EventManager implements the latter.
  • Adds configuration to the Bootstrap in setupLocator() to mark the EventManager as an unshared instance.

One issue is known, however:

  • Zend\Module\Listener\LocatorRegistration currently fails, as it assumes a StaticEventManager instance. As such, it cannot connect to the bootstrap event. I'm not sure what the solution for this will be -- I assume we'll need to instantiate a SharedEventManager and pass it into the Module\Manager, Mvc\Bootstrap, and potentially Mvc\Application. This will require documentation, and coordination with the skeleton application. Another alternative is to have this listener instead attach directly to the Bootstrap, and loop through the module manager. Ideas are welcome.
@Ocramius
Zend Framework member

Hey matt,
somehow missed this PR before (I'm really transient these weeks), but here I still see a big problem that can't be solved easily anyway, which is the singleton pattern.

Here's my use-case in short:

  1. Bootstrap "admin wrapper" application, run it
  2. Load ACL/whatever in "dispatch"
  3. Bootstrap sub-application (within dispatch) and inject ACL/whatever in it's service locator
  4. Run sub-application
  5. Use the response of the sub-application as response for the "admin wrapper" application

So the problem is that using a singleton would obviously re-triggering the dispatch (and the other MVC events) from the sub-application would affect the main application. Maybe I'm approaching the problem incorrectly, but the main issue still remains... Or am I getting this wrong?

@weierophinney
Zend Framework member
@Ocramius
Zend Framework member

Aha, then I'll have to read through it with more care when I got some spare time... Thank you :)

@weierophinney
Zend Framework member

@Ocramius So, I was replying from my phone over the weekend. Here's a better explanation. :)

The current architecture is that each class composing an EventManager receives a unique EventManager instance. This allows you to attach listeners locally, and they will only be notified if this EM instance triggers that event. Additionally, we have the concept of a "SharedEventManager". This is essentially simply a collection of listeners on events on specific contexts -- which are typically class names. The same instance of a SharedEventManager is injected into all EventManager instances (a capability recently made possible with the DIC). What this allows you to do is to listen to an event when you do not have direct access to the object or EM -- e.g., because it may not exist yet. When the EM triggers an event, it queries not only for local listeners on that event, but also those on the SharedEventManager, if any is composed.

(The StaticEventManager, as of this PR, is simply an extension of the SharedEventManager that implements a singleton interface; we would not be using it internally in the framework, but only providing it for those who want to use it.)

The key part of the SharedEventManager to note is that it has both the concept of an event and a context -- the latter allows fine-grained attachment of listeners -- so that if you want a "dispatch" listener on controllers, but not the application, you can use the context to make this happen. (This has been true of the StaticEventManager previous to this commit as well.)

@Ocramius
Zend Framework member

Thank you for explaining that :) I still have to wrap my mind around it, still haven't got any free time by now :\

@akrabat
Zend Framework member
akrabat commented Apr 19, 2012

Update for clean merge and docs to be added by @weierophinney

@akrabat akrabat was assigned Apr 19, 2012
weierophinney added some commits Mar 19, 2012
@weierophinney weierophinney Shared Collections support for EventManager
This is a solution for usage of the StaticEventManager. Basically, it
will instead expect the following:

- Classes composing an EventManager will implement EventManagerAware,
  and thus opt-in to setter injection of an EM instance
  - EM instances will _not_ be shared between classes
- The EM implements the SharedEventManagerAware interface, indicating it
  opts-in to setter injection of a SharedEventManager (note: not static)
  - A single "SharedEventManager" will be shared between all instances of
    EventManager

This commit does the following:

- Renames StaticEventCollection to SharedEventCollection
- Creates SharedEventManager, which implements all the functionality of
  StaticEventManager except the singleton aspects.
- StaticEventManager now extends SharedEventManager, and simply
  implements a singleton pattern.
- Introduced EventManagerAware and SharedEventManagerAware interfaces;
  EventManager implements the latter.
- Adds configuration to the Bootstrap in setupLocator() to mark the EventManager
  as an unshared instance.

It depends on work @ralphschindler is doing in his
feature/di-share-configuration branch.
2f06e47
@weierophinney weierophinney Updated events-aware classes to implement EventManagerAware
- Updated classes to implement EventManagerAware
- Updated tests to use SharedEventManager instead of StaticEventManager
f9ebfe7
@weierophinney weierophinney Renames for consistency
- s/SharedEventManagerAware/SharedEventCollectionAware/, as the
  interface was typehinting on the latter.
- s/setSharedConnections/setSharedCollections/, as the latter is the
  terminology in the interface
- s/sharedConnections/sharedCollections/, for the same reasons as the
  previous point
674881a
@weierophinney
Zend Framework member

Will now merge cleanly; need to (a) update docs, and (b) re-enable StaticEventManager awareness temporarily.

weierophinney added some commits Apr 19, 2012
@weierophinney weierophinney [#944] re-enable StaticEventManager awareness
- Re-enables StaticEventManager awareness temporarily until
  Application/Bootstrap is refactored to allow sharing a
  SharedEventManager instance and injecting into many discrete
  EventManager instances.
ac5535c
@weierophinney weierophinney [#944] Updated documentation
- Updated documentation to reference SharedEventCollection and SharedEventManager
- Made a note about StaticEventManager and that it's deprecated for use inside the framework
ef5fe43
@weierophinney
Zend Framework member

@akrabat Docs are updated, StaticEventManager usage (temporarily) reinstated, and merge conflicts handled. Ready to go!

@weierophinney weierophinney [#944] Fix failing tests due to EM changes
- Removed setEventManager() from ModuleHandler interface (cannot
  redefine methods when extending interfaces)
- s/(setSharedCo)ll(ections)/\1nn\2/ in MVC tests
0c5f6d8
@akrabat akrabat merged commit 0c5f6d8 into zendframework:master Apr 20, 2012
@ghost Unknown pushed a commit that referenced this pull request Jul 14, 2013
@weierophinney weierophinney [#944] re-enable StaticEventManager awareness
- Re-enables StaticEventManager awareness temporarily until
  Application/Bootstrap is refactored to allow sharing a
  SharedEventManager instance and injecting into many discrete
  EventManager instances.
a0105cf
@ghost Unknown pushed a commit that referenced this pull request Jul 14, 2013
@weierophinney weierophinney [#944] Updated documentation
- Updated documentation to reference SharedEventCollection and SharedEventManager
- Made a note about StaticEventManager and that it's deprecated for use inside the framework
a78b566
@ghost Unknown pushed a commit that referenced this pull request Jul 14, 2013
@weierophinney weierophinney [#944] Fix failing tests due to EM changes
- Removed setEventManager() from ModuleHandler interface (cannot
  redefine methods when extending interfaces)
- s/(setSharedCo)ll(ections)/\1nn\2/ in MVC tests
e512728
@pnx pnx pushed a commit to pnx/zf1 that referenced this pull request Mar 17, 2014
matthew Backported #944 from ZF2
- see zendframework/zf2#944
- renames StaticEventCollection to SharedEventCollection
- creates SharedEventManager, which implements SharedEventCollection, and is not
  a singleton
- StaticEventManager now extends SharedEventManager and implements a singleton

git-svn-id: http://framework.zend.com/svn/framework/standard/trunk@24700 44c647ce-9c0f-0410-b52a-842ac1e357ba
d72df5f
@weierophinney weierophinney added a commit to zendframework/zend-eventmanager that referenced this pull request May 15, 2015
@weierophinney weierophinney [zendframework/zf2#944] re-enable StaticEventManager awareness
- Re-enables StaticEventManager awareness temporarily until
  Application/Bootstrap is refactored to allow sharing a
  SharedEventManager instance and injecting into many discrete
  EventManager instances.
5eadfc8
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.