Re: [PEPr] +1 for Event::Dispatcher
| From: | Bertrand Mansion | Date: | Fri, 14 Jan 2005 23:28:29 +0000 |
| Subject: | Re: [PEPr] +1 for Event::Dispatcher | ||
| References: | 1 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-35497@lists.php.net to get a copy of this message | ||
Stephan Schmidt wrote:
>1. Event_Notification has a state as well as a cancel() and an
>isCancelled() method. This lets you stop the notification before it
>reaches other observers.
>(see ü.€Bð¦®^ÝÝ
>ºhttp://pear.php-tools.net/Event_Dispatcher/examples/cancel.phps)
>
>2. Event_Dispatcher objects may be nested for event bubbling.
>(see
>http://pear.php-tools.net/Event_Dispatcher/examples/bubbling.phps)
>
>3. Event_Dispatcher::post() returns the Event_Notification object
>instead of the count as it may store useful information. To get the
>count, use $notification->getCount()
>
>4. I introduced a EVENT_DISPATCHER_GLOBAL constant, as it took me some
>time to figure ot, why you could pass an empty string as notification name.
Looks like my version got on steroids !
So far, I agree your changes make the class even more interesting.
>5. Added a method to add objects by reference, as I did not know, that
>using array(&$obj, 'method') actually works. Maybe this could be removed.
I'd prefer to stick to what is offered by PHP. This construct is documented so
let's remove addObserverObject(). Maybe I could add more info about this in the
documentation.
>You'll find .phps files, examples, a unified diff as well as an tgz file
>of my changes at:
>
>http://pear.php-tools.net/Event_Dispatcher/
>
>Other things, I'd like to do:
>
>- Check (and possibly fix) all reference issues in PHP4
That'd be cool.
>- Allow custom notification classes:
>
>$disp = &Event_Dispatcher::getInstance();
>$disp->setNotificationClass('MyNotification');
If you use postNotification() instead of just post(), it takes an object as
parameter, so you are already free to post the kind of object you want.
One of the reasons why I used var $notificationName instead of just var $name,
etc. was so that properties don't collide with other properties if
Event_Notification is subclassed. I will probably do the same with your new
properties and methods unless you have another idea ?
So Event_Notification is to be seen more like an "abstract" class.
>This is useful if you need to store more information in the notification
>and it does not cost you anything...
Sure, although there is the $info array for this very purpose. The notification
can also contain an object.
>I hope you like my changes, would be great to have them included.
Yes, that's very nice from you and I'd be happy to integrate them. If you are
interested in being one of the developer (maintainer) of this package, please
let me know.
Thanks,
Bertrand