-- Greg <[email protected]> wrote (on Tuesday, 20 March 2012, 02:36 AM -0500): > I'm concerned that this code is being pushed into ZF1 so soon. In my > mind (tonight), PHP event driven programming boils down to how > processes are either registered or implemented. And with the right SOA > this isn't really a problem. Furthermore, registering event > listeners/handlers in PHP from a performance point of of view could > happen in various ways (some may still be unknown to me). Yet in > another thread you stated that in the next ZF2 beta release you would > like to iron out if and how event listeners can be retrieved from the > DIC. This concerns me in that we may now end up going down a 'bolted > on' path within ZF1 (and ZF2).
The EventManager in ZF1 is simply being offerred as a component. We're not doing any work to integrate it into other components. The backporting is occurring because I've fielded a large number of requests from ZF1 users who would like the functionality for their ZF1 applications -- no more, no less. I actually haven't been discussing retrieving event listeners from the DIC at all -- I _have_ been discussing injecting a "SharedEventManager" into EventManager instances, so we don't need to use the singleton StaticEventManager version. Which addresses the following: > As you know, I am extremely concerned by the usage of the > StaticEventManager. I actually have that work done in a branch right now, but it raises some issues with some design choices we've made in the MVC previously, which we'll now need to address. > I would also say, that as you previously stated > that this concept was modeled after a Java implementation, that I am > concerned about its usage in PHP. Back then when I read the Java > documentation (which I can't find anymore), it was not very elaborate, > but given that static usage in a Java web application is significantly > different than within PHP as that static Java resources persist across > all web requests, it leads me to believe that the static usage in Java > is only for low level processes, e.g cache, profiling etc - although > it was not very explicitly stated as such in their documentation. > > However, to date in ZF2 the usage of the StaticEventManager is for > high level processes that cannot be contained, as you say, within the > object the graph. Actually, it's not modelled on a Java implementation. I borrowed ideas from a variety of sources -- JavaScript's events system, Dojo's PubSub, Symfony 2's EventDispatcher, Zeta Component's SignalSlot implementation, Lithium's filters, Django's Signals, and more -- as well as lots of studying of Subject/Observer, Aspect Oriented Programming, Filter Chains, and other patterns. StaticEventManager follows the design of Zeta Components' SignalSlot more than any other implementation. The purpose is, quite simply, to allow attaching listeners without having direct access to the EM instance and/or component composing the EM instance. This is a well-defined use case at this time. > I would like to see event handlers, but I would rather wait to see it > solidified in ZF2, with well defined use cases, prior to it being back > ported to ZF1. > > This suggests to me, that we would need to see a ZF1 DIC > implementation first. We have very well-defined use cases for the EventManager already, and a clear use case for the StaticEventManager -- which is completely optional in usage. Additionally, as explained before, there are no ties between DIC and the EventManager; the only question is if there's a way to alter the EM to be more DI friendly with regards to shared event collections. Since we have no DIC in ZF1 -- and no plans to backport it, as it relies much too heavily on PHP 5.3-specific features -- I see no conflict here. -- Matthew Weier O'Phinney Project Lead | [email protected] Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc -- List: [email protected] Info: http://framework.zend.com/archives Unsubscribe: [email protected]
