<p>Great start! I know this proposal is in it's infancy but I would like to give a few suggestions to help jumpstart this proposal.</p>

<p>1. IMO, for all row-based methods, it's redundant to include $table as one of the parameters since the $row already has a public method to fetch the table: Zend_Db_Table_Row_Abstract::getTable();</p>

<p>2. Zend_Db_Table_Plugin_Interface::getRowColumn doens't need the 3rd param "$value":<br />
public function getRowColumn(Zend_Db_Table_Row_Abstract $row, $columnName);</p>

<p>3. In your My_Plugin_Date example above I already see some issues with redundancy. Many of these types of callbacks require the same functionality "onSave" (not necessarily insert or delete). What are your thoughts on just having a preSave() and postSave() then adding the following function to Zend_Db_Table_Row_Abstract?</p>
<ac:macro ac:name="code"><ac:plain-text-body><![CDATA[
class Zend_Db_Table_Row_Abstract
{
// ...
public function isNew()

// ...
}

class My_Plugin_Date extends Zend_Db_Table_Plugin_Abstract
{
public function preSave(Zend_Db_Table_Row_Abstract $row)
{
$date = Zend_Date::now();
if (true === $row->isNew())

$row->modified = $date->getIso();
}
}
]]></ac:plain-text-body></ac:macro>

<p>4. What about table-based settings? For instance with your My_Plugin_Date 'created' and 'modified' are hardcoded. Allowing the user to specify which columns represent these two cases would extend the functionality further:</p>

<ac:macro ac:name="code"><ac:plain-text-body><![CDATA[
class Article extends Zend_Db_Table_Abstract
{
protected $_plugins = array(
'My_Plugin_Date' => array(
'onInsert' => array('created', 'created_on', 'inserted'), // multiple fields
'onUpdate' => 'modified' // or just a single field
)
);
}
]]></ac:plain-text-body></ac:macro>

<p>@Simon:</p>

<p>IMO, callbacks should be event-based only... not event-state-based.</p>

<p>Outside ZF:<br />
Think about an onClick() event in Javascript. The event doesn't care which element is calling it nor the state of that element. If that information is important then you pass the state into the callback: onClick(this);.</p>

<p>In ZF:<br />
The save() process itself is a SINGLE event whereas the state of the Row (both before and after the actual save) should carry little importance to which callbacks are fired once the process is complete. If the state does matter (which, I think would be the less common case) then there is the ability to check it within the callbacks.</p>

<p>Also, with having two callbacks based on a single event you are setting yourself up for a lot of repetition. Not to mention more ambiguity within your code if both preInsert() and preUpdate() have to call a 3rd user-defined method to share common code from both events:</p>

<ac:macro ac:name="code"><ac:plain-text-body><![CDATA[
public function preInsert($row)
{
$this->_doPreSave($row);
}

public function preUpdate($row)
{
$this->_doPreSave($row);
}

protected function _doPreSave($row)
{
// logic
}

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

<p>Idea++</p>

<p>Looks good, would love to see this for 1.6.</p>

<p>If I understood it correctly, a Plugin can currently only work inside a Db_Table, it has no possibility to add functions to the interface of a Db_Table/Db_Table_Row class. This could be needed for some plugins.</p>

<p>As reference you may also look at doctrine plugins:
<a class="external-link" href="http://www.phpdoctrine.org/documentation/manual/trunk/?chapter=plugins">http://www.phpdoctrine.org/documentation/manual/trunk/?chapter=plugins</a></p>

<ac:macro ac:name="note"><ac:parameter ac:name="title">Zend Comments</ac:parameter><ac:rich-text-body>
<p>The Zend Framework team approves this proposal for immediate development in the<br />
standard incubator, with the following requirements/suggestions:</p>
<ul>
<li>Add a setConfig() method to Zend_Db_Table_Plugin_Abstract<br />
This method should proxy to setOptions(), and accept a Zend_Config object; please follow the example set by Zend_Form and family. The main reason for this request is consistency in the framework.</li>
<li>Plugin Broker should use Zend_Loader_PluginLoader. You may already be planning this, but it is unclear from the use cases and class skeletons. When used, you should also provide an accessor for the PluginLoader, to allow custom plugin loaders as required by end users.</li>
<li>No indication of where/when the broker is attached to the table class<br />
The table class should have public accessors for the broker (at minimum, getPluginBroker()).</li>
<li>registerPlugin() should allow concrete instances (unclear from use cases).<br />
Again, this is for a consistent story with plugins; you can look at Zend_Form for a representative implementation (specifically, addElement(), addDecorator(), etc.).</li>
</ul>
</ac:rich-text-body></ac:macro>

<p>First I really like this idea and thanks to the great work so far, I have even created a little image uploading/transformation plugin that is inspired by UploadColumn and PaperClip for ruby on rails, if you would like to try it out it is hosted at <a href="http://gitorious.org/projects/gem">gitorious</a>, it is in a early face so expect it to be broken.</p>

<p>However I found some problem when I put together a couple of plugins and where calling save (or any other method that is calling notify internally) on a row object from a different table that did not had any plugins registred. I then found out that notify where trying to notify my plugins for all the tables that where involved in the request.</p>

<p>Not sure if I might have misunderstood the expected behavior, but attached is a patch that solves the above.<br class="atl-forced-newline" /></p>
<ac:macro ac:name="code"><ac:plain-text-body><![CDATA[
Index: Zend/Db/Table/Plugin/Broker.php
===================================================================
— Zend/Db/Table/Plugin/Broker.php    (revision 11111)
+++ Zend/Db/Table/Plugin/Broker.php    (working copy)
@@ -140,7 +140,7 @@
         }
        
         foreach ((array) $className as $class)

     }
 
@@ -193,16 +193,20 @@
 
     /**
      * Notify plugins of an event
-     *
-     * @param  Zend_Loader_PluginLoader_Interface $loader
+     *
+     * @param Zend_Db_Table_Abstract $className
+     * @param string $suffix
+     * @param array $args Arguments that should be passed to the plugin
+     * @return integer|boolean Returns number of plugins notified or false if
+     *                         a plugin returns false.
      */
     static public function notify($className = null, $suffix = null, Array &$args = array())
     {
-        $plugins = Zend_Db_Table_Plugin_Broker::getPlugins($className);
+        if (false === self::hasTablePlugins($className))

 
-        if (!$plugins)

+        $plugins = Zend_Db_Table_Plugin_Broker::getTablePlugins($className);
 
         $method     = array_shift($args);
         $ret        = count($plugins);
@@ -368,4 +372,23 @@
 
         return self::getPlugin($plugins);
     }
+
+    /**
+     * Does a table have any plugins?
+     *
+     * @param string|Zend_Db_Table_Abstract $tableClass
+     * @return boolean
+     */
+    static public function hasTablePlugins($tableClass)
+    {
+        if ($tableClass instanceof Zend_Db_Table_Abstract)

+
+        if (isset(self::$_table[$tableClass]))

+        return false;
+    }
+   
 }
]]></ac:plain-text-body></ac:macro>

<p>This proposal has not been updated in the past 6 months. Archiving for now.</p>

<p>What is happening with this proposition, It would be cool to have this feature in ZF !</p>