Hey Jeremiah!
I was wondering what the best format would be to have this both editable
and still included in the docs.
I was looking into YUML ( http://yuml.me/ ), which I already use for
DoctrineORMModule and OcraServiceManager, but if I recall this correctly,
there's legal issues in hotlinking YUML in the docs, and it's also not well
suited for process flow diagrams.
If someone has a better tool that generates a graph that is maintainable by
others too, I can move that document to the official ZF2 documentation :)
Marco Pivetta
http://twitter.com/Ocramius
http://ocramius.github.com/
On 16 May 2013 06:50, Jeremiah Small wrote:
> 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 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
>> 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\Mv
