<p>Hi Jurren, I really like your proposal, it's a simple and powerful solution to system notifications.</p>

<p>Some feedback</p>

<ac:macro ac:name="code"><ac:default-parameter>php</ac:default-parameter><ac:plain-text-body><![CDATA[
Zend_Notification_Center {
// public function postNotification($name, $object, array $userInfo = array())
public function postNotification($message, $object, array $info = array())
}

Zend_Notification {
// public function getName()
public function getMessage()

// public function getUserInfo()
public function getInfo()
}
]]></ac:plain-text-body></ac:macro>

<p>IMO, it would be more appropriate changing $name for $message and $userInfo for $info. That way you can get the message using $notification->getMessage() - instead of $notification->getName().</p>

<p>Also, Zend_Notification can refer to anything. System notification, event notification, reminders, etc. So I think this is a great opportunity to introduce a Zend_System component:</p>

<p>Zend_System_Notification</p>

<p>Well done <ac:emoticon ac:name="smile" /></p>

<p>I like this proposal a lot. Imho the observer pattern is a very powerful and useful one, that has a place in a framework. The only thing that I'm not entirely sure about is the interface, it allows for just one method (notify()), where some people may rather see a callback.</p>

<p>You don't seem to be using SPL's observer class, is there a reason for this? </p>

<p>Hi there, I'm very happy to see this proposal as I think it's something much needed in a framework. I have my own event handling implementation, and it's very close to the one proposed here, so I won't say I kinda like it (oops I said it), but I think it lacks some advanced feature to be really powerful:</p>

<p>The notification center could allow observers to register to more than one notification at a time. It could be achieved via a simple globing mechanism or by allowing the second argument to be an array:</p>

<ac:macro ac:name="code"><ac:plain-text-body><![CDATA[
<?php
// imagine the Blog_Post model exposes the post.new, post.update and post.delete events
$postObserver = new Blog_Post_Observer;
$notificationCenter->addObserver($postObserver, 'post.*'); // globing example $notificationCenter->addObserver($postObserver, array('post.new', 'post.update')); // array example
?>
]]></ac:plain-text-body></ac:macro>

<p>of course the globing feature relies on a strict event naming convention. For the sake of keeping the api simple, when registering multiple events, the callback, if any, should be the same for all registered events.</p>

<p>The notification center could benefit from lazy observer loading. Imagine you register an observer for an event that will be triggered only under some circumstances so that the observer is not likely to be used each time the app is running. The addObserver could allow the first argument to be a string to deal with this:</p>

<ac:macro ac:name="code"><ac:plain-text-body><![CDATA[
$notificationCenter->addObserver('Blog_Post_Observer', 'post.*');
]]></ac:plain-text-body></ac:macro>

<p>The notification center would then instanciate the observer on the fly and only when needed, which could result in a performance gain.</p>

<p>Last, I'd like to throw in some random ideas:</p>

<ul class="alternate">
<li>should an event be cancelable by an observer ? this would prevent further propagation of the event</li>
<li>should an event be updatable by an observer ? like adding/updating/deleting data from it ? not sure it sticks with the spirit of the observer pattern tho.</li>
</ul>

<p>I've been doing some research and here are some observations: </p>

<p>1. We are dealing with an event notification system. That's how this type of component is better known in other languages. So, some possible names are: Zend_System_Event or Zend_Event. </p>

<p>2. Maybe Zend_Notification_Center can be called Zend_Event_Source? In Java for example, an event "listener" is an object that receives notification of events and an event "source" is an object that generates them.</p>

<p>3. addObserver() method can be renamed to registerEvent() for example, to keep it more consistent with other languages.</p>

<p>4. You might need an Event object implementing an interface. So you wrap the the observer object (or class name), the name, selector (or callback?) and inject it into Zend_Event_Source. This way users can extend the Event object.</p>

<p>5. postNotification(), is better known as postEvent() or sendEvent(). And keep in mind that post and send have different meanings.</p>

<p>So, you could have event notifications, but also implement an interface in case someone wants to add another type of event in the future:</p>

<ac:macro ac:name="code"><ac:default-parameter>php</ac:default-parameter><ac:plain-text-body><![CDATA[
class Zend_Event {
}
interface Zend_Event_Interface {
}
class Zend_Event_Notification {
}
class Zend_Event_Trigger {
}
class Zend_Event_Logger {
}
]]></ac:plain-text-body></ac:macro>

<p>And following the CoffeShop example:</p>

<ac:macro ac:name="code"><ac:default-parameter>php</ac:default-parameter><ac:plain-text-body><![CDATA[
class CoffeeShop_Customer
{
public function __construct()

...
}
]]></ac:plain-text-body></ac:macro>

<p>I agree, naming should be more towards a nice API, getInstance(), etc.. Zend_Event_Notify.</p>

<p>I don't know, Jurrien, I really don't see anything here that's not already covered by the SPL interfaces. The reason those interfaces don't have additional parameters is because the idea is for subjects to be able to report on their state via a <code>getState()</code> method.</p>

<p>In other words, when the <code>notify()</code> method is called for the subject, it iterates through its observers and calls <code>update()</code> on them all. Within each observer's <code>update()</code> method, they would typically call something like <code>getState()</code> to get any relevant state information, and then if necessary call any additional methods on the subject using that information.</p>

<p>So with no offense intended, I guess I'm having trouble seeing the value this proposal adds.</p>

<p>The idea is good, the only problem is the way you approached it. If you want to build a system that implements a complex network of interconnection between objects, you'll definitely need an Event Notification System, and ZF doesn't have one. But, in your proposal you are focusing to much on the observer pattern, and although the pattern is important, you need to focus more on what you want to achieve, and not how you want to achieve it.</p>

<p>I would change your example to something like this:</p>

<p>Classes:</p>
<ac:macro ac:name="code"><ac:default-parameter>php</ac:default-parameter><ac:plain-text-body><![CDATA[
class Zend_Event_Notify {
}
class Zend_Event_Notify_Request {
}
class Zend_Event_Notify_Response {
}
class Zend_Event_Notify_Response_Interface {
}
class Zend_Event_Log {
}
]]></ac:plain-text-body></ac:macro>

<p>Example: </p>
<ac:macro ac:name="code"><ac:default-parameter>php</ac:default-parameter><ac:plain-text-body><![CDATA[
class CustomerController extends Zend_Controller_Action
{
public function orderAction()

}
class CoffeeShopController extends Zend_Controller_Action
{
const ORDER_READY = 'order_ready';
const ORDER_ONHOLD = 'order_onhold';
const ORDER_CANCELED = 'order_canceled';

public function processOrder($order, $customerId)
{
$alertCustomer = false;
$data = array();

foreach ($order as $item) {
$data[$item]['price'] = $this->getPrice($item);
$data[$item]['stock'] = $this->checkAvailability($item);
if (! $data[$item]['stock'])

}

$manager = Zend_Event_Notify::getInstance();
if (true === $alertCustomer)

else

}
}
]]></ac:plain-text-body></ac:macro>

<p>The Customer object makes an order and requests a notification. The Coffee Shop processes the order and posts a notification. If an item is not available, the Manager of the Coffee shop is notified and the event logged. If all the items are available, then the Stock Manager is notified and the products restocked. </p>

<p>It might look silly when interconnecting 2 objects, like in the example above, but it's very useful when working with complex network of objects. </p>

<p>Ive to say, that i dont read the comments, but whats the matter of dont using the spl's Subject/Observer-Pattern?</p>

<p>Jurrien,</p>

<p>Could you perhaps talk about practical use cases that this component attempts to provide for? The coffeeshop example is a bit to abstract for me to fully get a grasp on the problem area.</p>

<p>Just so you can see where I am coming from, I think the real reason why a push based notification system is not included in SPL is b/c it (on its own) is not condusive to the nature of php. What I mean by that, is since PHP is a build-up/tear-down environment (per request), and since its primary audience is the web, how does the observer pattern apply here? Is the thinking that it is more suited for CLI? If you are using this for a use case within a web application.. how is persistence handled (since for example, posting of a blog happens in a request different than a request receiving the notification that the even has happened).</p>

<p>Java is more suited for the observer pattern (specifically push based systems) since the application maintains its state within Java, where as PHP requires the use of application code (ext/session for example) to persist state.</p>

<p>Long winded I know, but figured I'd ask for some clairity in this department.</p>

<p>-ralph</p>

<p>A few suggestions...</p>

<p>1. The existence of the interface is a bit odd, since you can set your own custom callback method. I don't think it adds a lot of value. I would require a callback method to be specified (no default) and ditch the interface altogether. Actually, the default callback notify() is detrimental because it will confuse users who expect the subject to do the notifying (the standard Subject/Observer nomenclature).</p>

<p>2. I would replace all the get()/remove()/has() methods with a simple getInstance(). Don't worry about namespaces unless users request it down the road – it would be an easy thing to add in later. If you think namespaces are important, I think a use case would be helpful to demonstrate why.</p>

<p>3. Everyone seems to have naming suggestions, but here's mine:</p>

<ac:macro ac:name="tip"><ac:rich-text-body>
<p>Zend_Message (from Zend_Notification_Message)<br />
Zend_Message_Dispatcher (from Zend_Notification)</p></ac:rich-text-body></ac:macro>

<p>I think that most clearly communicates the purpose of the class.</p>

<p>4. Your current API does not account for the possibility of a simple function callback. Doing so would be easy and would be in line with standard PHP behavior regarding callbacks.</p>

<p>Object oriented:</p>
<ac:macro ac:name="code"><ac:plain-text-body><![CDATA[
// class My_Observer

$messageDispatcher = Zend_Message_Dispatcher::getInstance();
$messageDispatcher->attach(array($this, 'update'), My_Subject::EVENT_MODIFIED);
// Alternately, $this can be a string for static callbacks
]]></ac:plain-text-body></ac:macro>

<p>Functional:</p>
<ac:macro ac:name="code"><ac:plain-text-body><![CDATA[
$messageDispatcher = Zend_Message_Dispatcher::getInstance();
$messageDispatcher->attach('doSomething', My_Subject::EVENT_MODIFIED);
]]></ac:plain-text-body></ac:macro>

<p>5. Rename post() to notify(). That's the standard nomenclature.</p>

<p><ac:emoticon ac:name="smile" /></p>

<p>@Ralph: Java is more suited for the observer pattern</p>

<p>Not really. Event notification systems are language agnostic, the play a fundamental role in, for example, a plug-in architecture. The host usually manages registered plug-ins, which can request notification from the host and act on certain events. Although it's optional, I've never implemented a plug-in architecture without using the observer pattern. </p>

<p>@Matt: 3. I like the Zend_Message naming suggestion. </p>

<p>Zend_Notification<br />
Zend_Message_Notification<br />
Zend_Event_Notification</p>

<p>Isn't message to generic?</p>

<p>@Matt: 5. Rename post() to notify()</p>

<p>I'm in favor of using notify() as well.</p>

<p>I still think Message it to generic and has different meanings, see <a href="http://en.wikipedia.org/wiki/Message_passing">Message passing</a></p>

<p>As you may now, Symfony 1.1 introduced an event notification system inspired by Cocoa, although I want to believe it was inspired by Jurrien <ac:emoticon ac:name="wink" /></p>

<p>The API is very simple, it consists of 2 classes, Event and EventDispatcher:</p>

<ac:macro ac:name="code"><ac:default-parameter>php</ac:default-parameter><ac:plain-text-body><![CDATA[
class sfEvent implements ArrayAccess
{
public function __construct($subject, $name, $parameters = array())
{}

public function getSubject()
{}

public function getName()
{}

public function setReturnValue($value)
{}

public function getReturnValue()
{}

public function setProcessed($processed)
{}

public function isProcessed()
{}

public function getParameters()
{}

public function offsetExists($name)
{}

public function offsetGet($name)
{}

public function offsetSet($name, $value)
{}

public function offsetUnset($name)
{}
}

class sfEventDispatcher
{
public function connect($name, $listener)
{}

public function disconnect($name, $listener)
{}

public function notify(sfEvent $event)
{}

public function notifyUntil(sfEvent $event)
{}

public function filter(sfEvent $event, $value)
{}

public function hasListeners($name)
{}

public function getListeners($name)
{}
}
]]></ac:plain-text-body></ac:macro>

<p>When comes this Proposal to the Labs or Release? I have my own implementation or plan to write a own Proposal or maybe take this over if the proposer is inactive.</p>