I wish I could, but I don't have the expertise to update it, and the version I know of is out of date, last I was told :-(
https://docs.google.com/drawings/d/1OwFfjgaiXDuKmS2I8nnJNFqoDgEWNNB-_-tUXUPVrgQ/view?pli=1 Does anyone know if it's been updated, and/or could someone who knows the details intimately help out Evan and update it? Or, does anyone know of a different version that is up to date and available on the web? I saw a pdf by Martin Keckeis last December, but not sure where to get that or who updates it. Seems like having it be "blessed" and in the docs will make it more official On May 15, 2013, at 4:57 PM, Marco Pivetta wrote: > @Jeremiah you can fetch it and add it to the documentation yourself ;) > > Marco Pivetta > > http://twitter.com/Ocramius > > http://ocramius.github.com/ > > > On 15 May 2013 18:33, Jeremiah Small <m...@jsmall.us> wrote: > This is a very useful post. > > Is the application flow map that Evan Coury created as a Google Doc going to > get updated and folded into the documentation? > > I found that very useful, but it fell out of date in the beta rounds. It > would be a great addition to the docs, because it's very hard to know what > events will fire when without it. > > Jeremiah > > On May 13, 2013, at 4:40 AM, Matthew Weier O'Phinney wrote: > > > On Mon, May 13, 2013 at 12:20 AM, David Muir <davidkm...@gmail.com> wrote: > >> On 10/05/13 23:11, Michael Gooden wrote: > >>> It should not be firing twice, however you are trying to use the shared > >>> event manager the wrong way. > >>> > >>> If you want to have a listener fire for EVERY dispatch ever, then just > >>> attach to normal event manager on EVENT_DISPATCH in one place. If you > >>> attach > >>> it in the MyModule it will still fire when you access a controller in the > >>> Application module. Is that what you need? > >> > >> > >> It was more as an experiment to see what would happen. I was more confused > >> by different tutorials showing listeners being attached to the EventManager > >> and the SharedEventManager without explaining why one should be used over > >> the other. > >> > >> As for firing twice, I agree, that shouldn't be happening, but > >> Zend\Mvc\Application.php triggers MvcEvent::EVENT_DISPATCH on line 309 and > >> Zend\Mvc\Controller\AbstractController triggers it on line 115. > >> In my opinion this is a bug, and those should be two separate events, but > >> there's probably not much that can be done about it now without breaking > >> BC. > > > > They *ARE* two separate events, that simply happen to be named the same. > > > > What do I mean? > > > > Each object composes its own EventManager instance. This is not > > shared, and the fact that the instance is not shared is purposeful: > > it's to allow each object to trigger isolated events, as well as to > > prevent naming collisions. This latter is important -- you can have > > the same event name in multiple objects, but they will not trigger the > > same listeners due to the fact that the EM instances are separate. > > > > If you want a listener to trigger for the same event name on different > > objects, you have two choices: > > > > - attach to each object's EM instance separately > > - attach to the SharedEventManager, specifying identifiers for each object > > > > The SharedEventManager is a shared container passed to all EM > > instances that were originally pulled from the ServiceManager. This > > object allows listeners to attach to events on objects with specific > > identifiers; when an event is triggered, the event manager will query > > the SharedEventManager to see if it has any listeners on identifiers > > it is interested in that correspond to the current event; if so, it > > will trigger those, too. > > > > This explains your original question: > > > >> Can someone explain why the shared event listener attached via the > >> Application module never gets called? > > > > When you attached to the SharedEventManager, you were attaching the > > the identifier "Application", which will only get triggered by an > > object that has the identifier "Application" -- most likely, this will > > be a controller, as the default controller implementations will add > > their top-level namespace as an event identifier. > > (Zend\Mvc\Application does not itself define that identifier, but > > instead the identifier "Zend\Mvc\Application".) > > > > You also ask the following: > > > >> Secondary to this, I've seen some examples attach listeners to the shared > >> manager, and others attach them to the event manager. When do I use one > >> instead of the other? > > > > The general rule of thumb is: > > > > - If you already have direct access to an object, and want to attach > > listeners to it, use its composed EventManager directly. > > - If you do not already have direct access to an object, or do not > > know if it will even come into scope in the current request, use the > > SharedEventManager to attach listeners. > > > > So, as concrete examples: Let's say I want to attach an event to > > trigger when routing has finished. I will generally do this during the > > bootstrap event from within my module. Inside a bootstrap listener, I > > can access the Application instance directly via either > > $e->getTarget() or $e->getApplication(). Since the route event is > > triggered directly by the Application instance, I can attach directly > > to its EM instance: > > > > $application = $e->getTarget(); > > $events = $application->getEventManager(); > > $events->attach('route', $callback, -10); > > > > Now let's say I want to attach a listener to an event triggered by a > > domain model. I don't know yet if that model will be used in this > > request, much less if the controller that will communicate with it > > will be selected. As such, I'll use the SharedEventManager, which I > > will pull from the EM instance composed in the Application instance. > > > > $application = $e->getTarget(); > > $events = $application->getEventManager(); > > $sharedEvents = $events->getSharedManager(); > > $sharedEvents->attach('My\Domain\Model', 'fetch', $callback); > > > > Hopefully that answers the questions you have! > > > >> > >> Cheers, > >> David > >> > >>> > >>> Cheers, > >>> > >>> Michael > >>> > >>> > >>> > >>> On 10 May 2013 15:01, David Muir <davidkm...@gmail.com > >>> <mailto:davidkm...@gmail.com>> wrote: > >>> > >>> Michael, > >>> > >>> Thanks for the explanation. It does explain the issue I have having. > >>> > >>> So the gist is: > >>> > >>>> $sharedEvents->attach(__NAMESPACE__, MvcEvent::EVENT_DISPATCH > >>>> > >>> > >>> means that this even will only be triggered if the context is that > >>> namespace. So the one in Application will fire if the context is > >>> "Application" and the one in MyModule will fire if the context is > >>> "MyModule". > >>> > >>> So as an experiment, in Application I tried attaching a listener > >>> to 'MyModule' instead of __NAMESPACE__ and it work as expected. It > >>> only fires when hitting a controller in MyModule. > >>> > >>> But what if I want to attach something that is triggered in all > >>> contexts on the dispatch event? I tried using the * wildcard, but > >>> now the shared listeners get hit twice: > >>> > >>> shared event listener from application module called > >>> shared event listener from my module called > >>> event listener from application module called > >>> event listener from my module called > >>> shared event listener from application module called > >>> shared event listener from my module called > >>> > >>> If my understanding is correct, this happens because there are two > >>> EventManager involved. First is the Application's EventManager, > >>> which first triggers the shared events, then triggers the local > >>> events. Then the controller itself triggers > >>> MvcEvent::EVENT_DISPATCH on its own EventManager instance when the > >>> controller's dispatch() method gets called. This in turn triggers > >>> the shared events a 2nd time. > >>> > >>> I guess I got exactly what I asked for, but wasn't > >>> expecting MvcEvent::EVENT_DISPATCH to be triggered twice. Kind of > >>> feels wrong... > >>> > >>> Cheers, > >>> David > >>> > >>> On 10/05/2013, at 4:46 PM, Michael Gooden > >>> <mich...@bluepointweb.com <mailto:mich...@bluepointweb.com>> wrote: > >>> > >>>> Hi David, > >>>> > >>>> Keep in mind that you are working with the Zend\Mvc\Application's > >>>> EventManager instance. Try and follow the code execution in the > >>>> Application::run() function, to see when and why different events > >>>> fire. > >>>> > >>>> I would hazard a guess and say that you are accessing a > >>>> controller in the MyModule, and not in the main Application > >>>> module. If you run a controller from the Application module, you > >>>> will then see the 'shared event from application' message show > >>>> instead of from mymodule. The reason this is happening is because > >>>> the shared event manager listener you are attaching is listening > >>>> for the event identifier of __NAMESPACE__. When the dispatch > >>>> event gets called against a controller under MyModule, only the > >>>> listener tied to the namespace of that controller will be fired. > >>>> The reason you will always see both normal event listener > >>>> messages is because those listeners are both attached to the > >>>> dispatch event. > >>>> > >>>> I feel I am failing at explaining this, can you add me on Skype? > >>>> > >>>> Cheers, > >>>> > >>>> Michael Gooden > >>>> > >>>> > >>>> On 10 May 2013 03:41, David Muir <davidkm...@gmail.com > >>>> <mailto:davidkm...@gmail.com>> wrote: > >>>> > >>>> I'm getting some weird behaviour with the EventManager and > >>>> SharedEventManager when used in the Application module vs > >>>> other modules. > >>>> > >>>> Application Module: > >>>> > >>>> public function onBootstrap(MvcEvent $e) > >>>> { > >>>> //$e->getApplication()->getServiceManager()->get('translator'); > >>>> $eventManager = > >>>> $e->getApplication()->getEventManager(); > >>>> $moduleRouteListener = new ModuleRouteListener(); > >>>> $moduleRouteListener->attach($eventManager); > >>>> > >>>> $eventManager->attach(MvcEvent::EVENT_DISPATCH, function > >>>> ($event){ > >>>> echo 'event listener from application module > >>>> called' . PHP_EOL; > >>>> }); > >>>> > >>>> $sharedEvents = $eventManager->getSharedManager(); > >>>> > >>>> $sharedEvents->attach(__NAMESPACE__, > >>>> MvcEvent::EVENT_DISPATCH, function ($event){ > >>>> echo 'shared event listener from application > >>>> module called'. PHP_EOL; > >>>> }); > >>>> > >>>> } > >>>> > >>>> > >>>> My Module: > >>>> > >>>> public function onBootstrap(\Zend\EventManager\EventInterface $e) > >>>> { > >>>> > >>>> $eventManager = > >>>> $e->getApplication()->getEventManager(); > >>>> $sharedEvents = $eventManager-> getSharedManager(); > >>>> > >>>> $eventManager->attach(MvcEvent::EVENT_DISPATCH, function > >>>> ($event){ > >>>> echo 'event listener from my module called'.PHP_EOL; > >>>> }); > >>>> > >>>> $sharedEvents->attach(__NAMESPACE__, > >>>> MvcEvent::EVENT_DISPATCH, function ($event){ > >>>> echo 'shared event listener from my module > >>>> called'.PHP_EOL; > >>>> }); > >>>> > >>>> } > >>>> > >>>> > >>>> > >>>> outputs: > >>>> > >>>> shared event listener from my module called > >>>> event listener from application module called > >>>> event listener from my module called > >>>> > >>>> > >>>> Can someone explain why the shared event listener attached > >>>> via the Application module never gets called? > >>>> > >>>> Secondary to this, I've seen some examples attach listeners > >>>> to the shared manager, and others attach them to the event > >>>> manager. When do I use one instead of the other? > >>>> > >>>> Cheers, > >>>> David > >>>> > >>>> > >>>> -- > >>>> List: fw-general@lists.zend.com > >>>> <mailto:fw-general@lists.zend.com> > >>>> > >>>> Info: http://framework.zend.com/archives > >>>> Unsubscribe: fw-general-unsubscr...@lists.zend.com > >>>> <mailto:fw-general-unsubscr...@lists.zend.com> > >>>> > >>>> > >>>> > >>> > >>> > >> > > > > > > > > -- > > Matthew Weier O'Phinney > > Project Lead | matt...@zend.com > > Zend Framework | http://framework.zend.com/ > > PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc > > > > -- > > List: fw-general@lists.zend.com > > Info: http://framework.zend.com/archives > > Unsubscribe: fw-general-unsubscr...@lists.zend.com > > > > > > > -- > List: fw-general@lists.zend.com > Info: http://framework.zend.com/archives > Unsubscribe: fw-general-unsubscr...@lists.zend.com > > >
