Phil Brown's Web Development Blog » PHP

Zend Framework and Doctrine Part 1

Phil — Tue, 17 Nov 2009 23:24:40 +0000

I’ve begun to investigate the Doctrine ORM library and how to integrate it into Zend Framework applications. I figure this post and any subsequent ones on the topic can grow into some sort of discovery series.

So, my first post is going to be a simple one – bootstrapping with Doctrine 1.2.

I figured the most robust and consistent way to get Doctrine into my applications was to create an application resource plugin so without further delay, here it is.

// library/Tolerable/Application/Resource/Doctrine.php
 
class Tolerable_Application_Resource_Doctrine extends Zend_Application_Resource_ResourceAbstract
{
    /**
     * @var Doctrine_Manager
     */
    protected $_manager;
 
    /**
     * @var Doctrine_Cache_Interface
     */
    protected $_cacheDriver;
 
    /**
     * @var string|array
     */
    protected $_cache;
 
    /**
     * @var array
     */
    protected $_connections = array();
 
    /**
     * Set cache options
     * 
     * @param string|array $cache
     * @return Tolerable_Application_Resource_Doctrine
     */
    public function setCache($cache)
    {
        $this->_cache = $cache;
        return $this;
    }
 
    /**
     * @return string|array
     */
    public function getCache()
    {
        return $this->_cache;
    }
 
    /**
     * Set connection configuration
     * 
     * @param array $connections
     * @return Tolerable_Application_Resource_Doctrine
     */
    public function setConnections(array $connections)
    {
        $this->_connections = $connections;
        return $this;
    }
 
    /**
     * Initialise and return Doctrine_Manager instance
     * 
     * @return Doctrine_Manager
     */
    public function getManager()
    {
        if (null === $this->_manager) {
            $manager = Doctrine_Manager::getInstance();
            $manager->setAttribute(Doctrine_Core::ATTR_MODEL_LOADING,
                                   Doctrine_Core::MODEL_LOADING_CONSERVATIVE);
            $manager->setAttribute(Doctrine_Core::ATTR_VALIDATE,
                                   Doctrine_Core::VALIDATE_ALL);
            $manager->setAttribute(Doctrine_Core::ATTR_AUTO_ACCESSOR_OVERRIDE, true);
            $manager->setAttribute(Doctrine_Core::ATTR_AUTOLOAD_TABLE_CLASSES, true);
            $manager->setAttribute(Doctrine_Core::ATTR_USE_DQL_CALLBACKS, true);
            $manager->setAttribute(Doctrine_Core::ATTR_AUTO_FREE_QUERY_OBJECTS, true);
 
            if ($cacheDriver = $this->_getCacheDriver()) {
                $manager->setAttribute(Doctrine_Core::ATTR_QUERY_CACHE, $cacheDriver);
            }
 
            $this->_manager = $manager;
        }
        return $this->_manager;
    }
 
    /**
     * Initialise and return query cache driver if configured
     * 
     * @return Doctrine_Cache_Interface|null
     */
    protected function _getCacheDriver()
    {
        if (null === $this->_cacheDriver) {
            $options = $this->getCache();
            if (empty($options)) {
                return null;
            }
 
            if (is_array($options)) {
                if (!array_key_exists('driver', $options)) {
                    throw new Zend_Application_Resource_Exception('Missing Doctrine cache driver');
                }
                $driver = $options['driver'];
                unset($options['driver']);
            } else {
                $driver = (string) $options;
                $options = array();
            }
 
            if (!class_exists($driver)) {
                Zend_Loader::loadClass($driver);
            }
 
            $this->_cacheDriver = new $driver($options);
        }
        return $this->_cacheDriver;
    }
 
    /**
     * Initialise any configured connections
     * 
     * @return void
     */
    protected function _initConnections()
    {
        foreach ($this->_connections as $name => $options) {
            if (!is_array($options)) {
                $options = array('dsn' => $options);
            }
 
            if (array_key_exists('charset', $options)) {
                $charset = $options['charset'];
                unset($options['charset']);
            } else {
                $charset = 'utf8';
            }
 
            // Attempt to find "dsn" or "connection_string" keys
            // falling back to an array of connection options
            if (array_key_exists('dsn', $options)) {
                $adapter = $options['dsn'];
            } else if (array_key_exists('connection_string', $options)) {
                $adapter = $options['connection_string'];
            } else {
                $adapter = $options;
            }
 
            $connection = $this->getManager()->openConnection($adapter, $name);
            $connection->setAttribute(Doctrine_Core::ATTR_USE_NATIVE_ENUM, true);
            $connection->setCharset($charset);
        }
    }
 
    /**
     * Initialise and return Doctrine manager
     * 
     * @return Doctrine_Manager
     */
    public function init()
    {
        $this->_initConnections();
        return $this->getManager();
    }
}

This class provides a reusable component to use in any ZF 1.8+ application. To enable the plugin, add the following to your application.ini file.

; Add the Doctrine and Tolerable namespaces to the autoloader
autoloaderNamespaces[] = "Doctrine_"
autoloaderNamespaces[] = "Tolerable_"
 
; Add our custom application resource plugin path to the plugin loader
pluginPaths.Tolerable_Application_Resource = "Tolerable/Application/Resource"

Configure the Doctrine query cache (if desired)

; Simple examples, no driver options
resources.doctrine.cache = "Doctrine_Cache_Apc"
 
; or with options
resources.doctrine.cache.driver = "Doctrine_Cache_Apc"
resources.doctrine.cache.option = ...
resources.doctrine.cache.option = ...
resources.doctrine.cache.option = ...

See here for drivers and options.

Configure the connections

; Simple connection strings
resources.doctrine.connections[] = "mysql://user1:pass@localhost/db1"
resources.doctrine.connections[] = "mysql://user2:pass@localhost/db2"
 
; or specify connection name and options
resources.doctrine.connections.default.dsn     = "mysql://user1:pass@localhost/db1"
resources.doctrine.connections.default.charset = "utf8"
 
; or specify Doctrine connection parameters
resources.doctrine.connections.default.scheme = "mysql"
resources.doctrine.connections.default.user   = "user1"
resources.doctrine.connections.default.pass   = "pass"
resources.doctrine.connections.default.host   = "localhost"
resources.doctrine.connections.default.path   = "db1"

This is assuming that your custom (Tolerable in these examples) and Doctrine libraries are under your application’s “library” path. If not, simply add them to the application’s include path configuration, for example

includePaths.library = APPLICATION_PATH "/../library"
includePaths.doctrine = "/path/to/doctrine/lib"
includePaths.custom = "/path/to/custom/library"

A lot of the code in the plugin has been taken from Matthew Weier O’Phinney’s blog post on Autoloading Doctrine and Doctrine entities from Zend Framework.

2009-11-19 Update

Some extra inspiration came from Juozas Kaziukenas’ post on Zend Framework and Doctrine. Part 2 as well as the twitter-verse and now the plugin handles multiple connections and caching.

Overriding Zend form element default decorators, for good!

Phil — Thu, 15 Oct 2009 01:55:22 +0000

I’m sure everybody who has used Zend_Form has, at one time or another, wished they could change the default form element decorators in one fell swoop, simply and efficiently.

Up until now, I’ve been using one of two methods to override the default “definition list” style; set each element’s decorator scheme on instantiation or, use the form’s “setElementDecorators” method to reset the scheme for nominated elements. No longer!

Using just a few simple classes, I’ll show you how to permanently alter the default decorator scheme, thus simplifying your code and making it ultimately more flexible.

For the following example, I’ll assume a decorator scheme like the following

form
  fieldset
    ol
      li
        label
        element
      li
        button

Lets start by extending Zend_Form_Element. I’d also like to take this opportunity to introduce my new “Tolerable” library.

// library/Tolerable/Form/Element.php
 
class Tolerable_Form_Element extends Zend_Form_Element
{
    /**
     * Load default decorators
     *
     * @return void
     */
    public function loadDefaultDecorators()
    {
        if ($this->loadDefaultDecoratorsIsDisabled()) {
            return;
        }
 
        $decorators = $this->getDecorators();
        if (empty($decorators)) {
            $this->addDecorator('ViewHelper')
                 ->addDecorator('Errors')
                 ->addDecorator('Description', array('tag' => 'p',
                                                     'class' => 'description'))
                 ->addDecorator('Label', array('requiredSuffix' => ' *'))
                 ->addDecorator('HtmlTag', array('tag' => 'li',
                                                 'id'  => $this->getName() . '-element'));
        }
    }
}

Don’t forget to add your library namespace to the auto loader

; application/configs/application.ini
 
autoloaderNamespaces.1 = "Tolerable_"

Zend_Form_Element_Submit also needs some treatment

// library/Tolerable/Form/Element/Submit.php
 
class Tolerable_Form_Element_Submit extends Zend_Form_Element_Submit
{
    /**
     * Default decorators
     *
     * Uses only 'Submit' and 'li' decorators by default.
     * 
     * @return void
     */
    public function loadDefaultDecorators()
    {
        if ($this->loadDefaultDecoratorsIsDisabled()) {
            return;
        }
 
        $decorators = $this->getDecorators();
        if (empty($decorators)) {
            $this->addDecorator('Tooltip')
                 ->addDecorator('ViewHelper')
                 ->addDecorator('HtmlTag', array('tag' => 'li'));
        }
    }
}

We’ll also need to provide our own display group class to support the desired scheme

// library/Tolerable/Form/DisplayGroup.php
 
class Tolerable_Form_DisplayGroup extends Zend_Form_DisplayGroup
{
    /**
     * Load default decorators
     * 
     * @return void
     */
    public function loadDefaultDecorators()
    {
        if ($this->loadDefaultDecoratorsIsDisabled()) {
            return;
        }
 
        $decorators = $this->getDecorators();
        if (empty($decorators)) {
            $this->addDecorator('Description', array('tag'   => 'li',
                                                     'class' => 'group_description'))
                 ->addDecorator('FormElements')
                 ->addDecorator('HtmlTag', array('tag' => 'ol'))
                 ->addDecorator('Fieldset');
        }
    }
}

as well as a custom form class

// library/Tolerable/Form.php
 
class Tolerable_Form extends Zend_Form
{
    /**
     * Default display group class
     * @var string
     */
    protected $_defaultDisplayGroupClass = 'Tolerable_Form_DisplayGroup';
 
    /**
     * Constructor
     *
     * Add custom prefix path before parent constructor
     *
     * @param mixed $options
     * @return void
     */
    public function __construct($options = null)
    {
        $this->addPrefixPath('Tolerable_Form', 'Tolerable/Form');
        parent::__construct($options);
    }
 
    /**
     * Load the default decorators
     *
     * @return void
     */
    public function loadDefaultDecorators()
    {
        if ($this->loadDefaultDecoratorsIsDisabled()) {
            return;
        }
 
        $decorators = $this->getDecorators();
        if (empty($decorators)) {
            $this->addDecorator('FormElements')
                 ->addDecorator('Form');
        }
    }
}

Now that we’ve laid the way for our custom decorator scheme, there’s only one item remaining and I can’t say that I’m proud but hey, it works.

All front facing (HTML) Zend form elements extend the empty, abstract class Zend_Form_Element_Xhtml. We’re going to override this class in its current form. This method works well if the Zend Framework is not in the application’s “library” which should have a higher “include path” setting than the framework itself. Otherwise, you’ll just have to override the existing Zend Framework file.

// library/Zend/Form/Element/Xhtml.php
 
abstract class Zend_Form_Element_Xhtml extends Tolerable_Form_Element
{
}

That’s it. Get ready to start writing leaner, meaner forms

$form = new Tolerable_Form;
$form->addElement('text', 'foo', array(
    'label'    => 'Foo',
    'required' => true
))->addElement('textarea', 'bar', array(
    'label'    => 'Bar'
))->addElement('submit', 'submit_btn', array(
    'label'    => 'Submit'
))->addDisplayGroup(
    array('foo', 'bar', 'submit_btn'),
    'baz',
    array('legend' => 'My Form')
);

PHP suExec and custom php.ini files

Phil — Mon, 17 Aug 2009 00:13:59 +0000

Lately, I’ve noticed more and more shared web hosts making the switch to running PHP under suExec. The benefits of this are:

PHP scripts run as the owning user
No more file system permission juggling
Scripts are generally sandboxed to the owner’s home directory

Unfortunately, this poses a problem for any custom PHP configuration changes as the usual .htaccess php_flag and php_value properties are no longer supported. The recommended method of setting a custom configuration is to place a php.ini file under each directory where required.

This method works fine for any properties set in the custom php.ini file however there appears to be one devastating omission. Server configuration properties do not cascade into the custom file. What this means is that for any property not set in your custom file, PHP will revert to the PHP default.

For example, say your host has enabled PDO (as any decent host should). The instant you introduce a custom php.ini file, PDO will be lost. Sure, you could just include the relevant extension_dir and extension properties but consider this example (from my host)

extension_dir = "/usr/local/lib/php/extensions/no-debug-non-zts-20060613"

That property is awfully specific and your custom entry wouldn’t fare too well in the event of an upgrade.

In a perfect world, the host would have compiled PHP with the --with-config-file-scan-dir=/some/dir option that allows an environmentally settable directory to be scanned for additional config files. Unfortunately, this is rarely the case.

My solution is a little hacky and hardly perfect but it certainly gets the job done for me.

1. Create your custom.ini file with the options you want. Mine is /home/user/etc/php.d/custom.ini and looks like this

register_globals = Off
magic_quotes_gpc = Off

Do not name this file php.ini.

2. Locate your host’s php.ini file. This information is available from phpinfo(). In the below examples it is /usr/local/lib/php.ini

3. Add a cron job to create a full php.ini file in a location of your choosing (/home/user/etc/php.d) that is the concatenation of the server php.ini file and your custom.ini file. The below example is set to run hourly with any errors displayed on stdout which should be mailed to the crontab owner.

0 * * * * /usr/bin/test -f /usr/local/lib/php.ini && /bin/cat /usr/local/lib/php.ini /home/user/etc/php.d/custom.ini > /home/user/etc/php.d/php.ini || echo '/usr/local/lib/php.ini NOT FOUND'

The reason for the cron job is to keep your full, custom php.ini file in sync with any server changes. The job will also inform you in the unlikely event that the host php.ini file is moved.

If you’ve got shell access, you can create this file immediately by running

cat /usr/local/lib/php.ini /home/user/etc/php.d/custom.ini > /home/user/etc/php.d/php.ini

otherwise, wait for the hour to come around in which case your cron job should have done the work for you.

4. Add the following to your web application’s .htaccess file

SetEnv PHPRC /home/user/etc/php.d

The PHPRC environment variable informs any PHP scripts of the location of the preferred php.ini file.

Enjoy.

Editor themes for Eclipse PDT – Obsidian

Phil — Thu, 30 Jul 2009 06:01:50 +0000

My PHP IDE of choice is Eclipse with the PDT plugin.

The thing is, I always feel a little snow blind after a day’s coding, staring at that white screen all day. So much so that I’ve undertaken the arduous task of tweaking my colour preferences to match the Obsidian theme found in the more recent versions of Notepad++. Why Eclipse can’t take some lead from Notepad++ and Aptana and make this process much easier, I don’t know but here’s the end result.

PHP file with Obsidian theme

Mixed PHP and HTML file with Obsidian theme

I’ve also created some preference files so you can play along at home. Please note that whilst I’ve made sure the preference files only contain colour data, I’ve only done minor testing but so far, everything has gone well. My setup is Eclipse Galileo with PDT 2.1 however I don’t think there’s any version specific stuff in the files.

To install the colour preferences:

Download one of the below packages and extract the contents to a temporary directory
Fire up Eclipse
Backup your current preferences by going to File -> Export -> General -> Preferences. Follow the instructions from there to create a preferences file. Make sure you choose “Export all”.
Go to File -> Import -> General -> Preferences and select the Obsidian/eclipse.epf file. Click “Finish”

I’ve also included some Aptana colourisation files for CSS and JavaScript however I haven’t yet created preferences for other Aptana editors.

Enjoy and keep watching for more themes.

Obsidian.tar.gz
Obsidian.zip

Extending Zend Framework Application Resource Plugins

Phil — Tue, 30 Jun 2009 01:21:50 +0000

With the arrival of Zend Framework version 1.8 came the application resource plugins. These nifty little classes help bootstrap your application’s resources (views, layouts, database connections, etc). The default behaviour is suitable for most needs however, occasionally, you’re going to want to perform some extra functionality.

Take for example the following use case – the standard DB resource plugin instantiates a database connection based on supplied parameters and registers it with Zend_Db_Table_Abstract::setDefaultAdapter(). What if you want to register the connection in the Zend_Registry as well? You could create a bootstrap method (_initRegistry() for example) and pull the adapter out of Zend_Db_Table_Abstract or you could simply extend the resource plugin.

// library/My/Application/Resource/Db.php
 
class My_Application_Resource_Db extends Zend_Application_Resource_Db
{
    public function init()
    {
        if (null !== ($db = $this->getDbAdapter())) {
            Zend_Registry::set('dbAdapter', $db);
        }
        return parent::init();
    }
}

This class simply adds the created database adapter to the registry before continuing on with the default behaviour.

To let the application know about your custom plugin, you simply add the plugin path to your application.ini file, eg

includePaths.library = APPLICATION_PATH "/../library"
pluginPaths.My_Application_Resource = "My/Application/Resource"

More reading is available here – http://framework.zend.com/manual/en/zend.application.theory-of-operation.html

Further examples here – http://framework.zend.com/manual/en/zend.application.examples.html

Changing layouts with Zend ContextSwitch

Phil — Tue, 10 Feb 2009 03:19:58 +0000

Ever since discovering Zend Framework’s ContextSwitch and AjaxContext action helpers, I’ve been hooked. What’s not to love about writing one controller action and having the request dictate the response format.

Whilst this generally does the job for XML, JSON and AJAX HTML snippets where any layout is disabled, sometimes you just need to wrap that content in something.

I often find myself writing small configuration screens that work nicely in modal style dialogs as opposed to a devoted web page. Generally I’ll render these screens as inline frames using my favourite JavaScript library and DOM Window (a ThickBox successor). The problem with iframes is they require a complete HTML document. ContextSwitch just wasn’t cutting it as I needed some kind of layout but obviously not the full blown, menus and all default.

The solution was to implement my own custom context, complete with a post-processing callback function to alter the layout script. Here’s how I’ve done it.

First, I added a static method to my Bootstrap class to add a suffix to the layout script name should a context be present.

public static function setLayoutContext()
{
    $layout = Zend_Layout::getMvcInstance();
    if (null !== $layout && $layout->isEnabled()) {
        $context = Zend_Controller_Action_HelperBroker::getStaticHelper('ContextSwitch')->getCurrentContext();
        if (null !== $context) {
            $layout->setLayout($layout->getLayout() . '.' . $context);
        }
    }
}

For example, given the default layout script layout.phtml and context iframe, this method will set the layout script to layout.iframe.phtml

Now I just need to add the context to the action helper. Again, in my Bootstrap class.

public static function setupActionHelpers()
{
    // This method is called during application bootstrapping
 
    // Add "iframe" context
    $iframeContext = array(
        'suffix'    => 'iframe',
        'callbacks' => array(
            'post' => array(__CLASS__, 'setLayoutContext')
        )
    );
 
    $contextSwitch = Zend_Controller_Action_HelperBroker::getStaticHelper('ContextSwitch');
 
    $contextSwitch->addContext('iframe', $iframeContext);
}

Ok, that’s all the preparation work out of the way. To add this context to a controller action, you simply, well, add it.

class MyController extends Zend_Controller_Action
{
    public function init()
    {
        $this->_helper->contextSwitch->addActionContext('config', 'iframe')
                                     ->setAutoDisableLayout(false)
                                     ->initContext();
    }
 
    public function configAction()
    {
        // Controller tasks here
    }
}

All that’s left to do is ensure your links to the context enabled controller action include the correct format parameter, for example /my/config/format/iframe or /my/config?format=iframe.

One thing I’ve noticed is that the ContextSwitch helper should be configured after your view and layout are initialised.

Thanks to Jeff Carouth for the inspiration for this post.

Zend Framework Forms and magic_quotes_gpc

Phil — Fri, 10 Oct 2008 02:05:45 +0000

Introducing the bane of my existence – PHP’s magic_quotes_gpc.

I won’t bore you with the details suffice to say that this is one of PHP’s greatest failings and I cannot wait until the world adopts PHP6 and this awful blight is removed forever. Until then, we’ll just have to deal with it.

Now, there are various ways of disabling this “feature” as outlined here but what if that isn’t an option? My particular host of choice, while being excellent in every other regard, has this little blighter enabled and runs PHP as a CGI via the suExec module. This means no php_flag or php_value entries in the .htaccess file and the current implementation of allowing custom php.ini files is totally broken (server php.ini items do not cascade through to the custom one, meaning paths are wrong, extensions aren’t loaded, etc). This prompted me to implement something in code which is what I’ll be sharing with you today.

The code solution to magic quotes is to use stripslashes(). The simplest way of getting this into the Zend Framework is to create a filter.

class MoreCowbell_Filter_StripSlashes implements Zend_Filter_Interface
{
    public function filter($value)
    {
        return get_magic_quotes_gpc() ? $this->_clean($value) : $value;
    }
 
    protected function _clean($value)
    {
        return is_array($value) ? array_map(array($this, '_clean'), $value) : stripslashes($value);
    }
}

This filter allows us to process not only strings but array values as well. Note that the filter only activates if magic quotes is enabled.

All my forms extend my own custom Zend_Form extension which simply provides some shortcuts to my preferred decorator scheme. I’ll add some extra shortcuts for the new filter.

class MoreCowbell_Form extends Zend_Form
{
    public $elementDecorators = array(
        'ViewHelper',
        'Description',
        array('Label',   array('requiredSuffix' => ' *')),
        array('Errors',  array('placement' => 'PREPEND')),
        array('HtmlTag', array('tag' => 'li'))
    );
 
    public $buttonDecorators = array(
        'ViewHelper',
        array('HtmlTag', array('tag' => 'li'))
    );
 
    public $groupDecorators = array(
        'FormElements',
        array('HtmlTag', array('tag' => 'ol')),
        'Fieldset'
    );
 
    // Configure path to custom plugins
    public $elementPrefixPaths = array('filter' => array(
        'prefix' => 'MoreCowbell_Filter',
        'path'   => 'MoreCowbell/Filter'
    ));
 
    // Shortcut to default element filters
    public $elementFilters = array(
        'StripSlashes'
    );
 
    public function loadDefaultDecorators()
    {
        $this->setDecorators(array(
            'FormElements',
            'Form'
        ));
    }
}

All that’s left to do is assign the appropriate configuration settings in your forms and all your input data will be purged of the magic quotes evil. Here’s an overly simple example of a blog entry form.

class My_Blog_Form extends MoreCowbell_Form
{
    public function init()
    {
        $this->addElement('text', 'blog_title', array(
            'label'      => 'Title',
            'required'   => true,
            'prefixPath' => $this->elementPrefixPaths,
            'decorators' => $this->elementDecorators,
            'filters'    => $this->elementFilters
        ))->addElement('textarea', 'blog_post', array(
            'label'      => 'Post',
            'required'   => true,
            'rows'       => 5,
            'cols'       => 10,
            'prefixPath' => $this->elementPrefixPaths,
            'decorators' => $this->elementDecorators,
            'filters'    => $this->elementFilters
        ))->addElement('submit', 'submit_btn', array(
            'label'      => 'Submit',
            'decorators' => $this->buttonDecorators
        ))->addDisplayGroup(
            array('blog_title', 'blog_post', 'submit_btn'),
            'blog',
            array(
                'legend'     => 'Blog Entry',
                'decorators' => $this->groupDecorators
            )
        );
    }
}

Zend Framework: Automatically fetch the grand total from a limit query

Phil — Wed, 20 Aug 2008 02:29:56 +0000

September 11, 2008 – Updated for Zend Framework 1.6

So you’ve got a nice limited result set for use in a paginated display. The thing with most pagination widgets is they need to know the grand total for determining the total number of pages.

What you would normally have to do is manually issue a second query to fetch the total based on the same parameters as the original query, minus the limit and offset (and order but that’s beside the point). Wouldn’t it be nice if this could all be done behind the scenes?

Enter the More Cowbell solution!

For the example, I’ll be assuming you’re using an implementation of the Zend_Db_Table_Abstract class and associated Zend_Db_Table_Rowset_Abstract however this solution is reasonably generic and can be easily applied to other situations.

First things first, lets extend the rowset class.


class MoreCowbell_Db_Table_Rowset extends Zend_Db_Table_Rowset_Abstract
{
    /**
     * Grande total for limited result sets
     * 
     * @var int
     */
    protected $_total;
 
    /**
     * Constructor
     * 
     * @param array $config
     */
    public function __construct(array $config)
    {
        parent::__construct($config);
 
        if(isset($config['total']) {
            $this->_total = (int) $config['total'];
        } else {
            $this->_total = $this->_count;
        }
    }
 
    /**
     * Returns the grande total
     *
     * @return int
     */
    public function total()
    {
        return $this->_total;
    }
}
?>

This simple extension allows us to store an arbitrary integer representing the grande total inside the resultset object. Now, on to the meat and potatoes.

Your usual Zend_Db_Table_Abstract implementation is a fairly simple affair; define a table name, primary key(s), etc. We’re going to add just a little more abstraction for your tables to inherit.


abstract class MoreCowbell_Db_Table_Abstract extends Zend_Db_Table_Abstract
{
    /**
     * Classname for rowset
     *
     * @var string
     */
    protected $_rowsetClass = 'MoreCowbell_Db_Table_Rowset';
 
    /**
     * Fetches all rows.
     *
     * Honors the Zend_Db_Adapter fetch mode.
     *
     * @param string|array|Zend_Db_Table_Select $where  OPTIONAL An SQL WHERE clause or Zend_Db_Table_Select object.
     * @param string|array                      $order  OPTIONAL An SQL ORDER clause.
     * @param int                               $count  OPTIONAL An SQL LIMIT count.
     * @param int                               $offset OPTIONAL An SQL LIMIT offset.
     * @return Zend_Db_Table_Rowset_Abstract The row results per the Zend_Db_Adapter fetch mode.
     */
    public function fetchAll($where = null, $order = null, $count = null, $offset = null)
    {
        // This is all straight out of Zend_Db_Table_Abstract::fetchAll()
 
        if (!($where instanceof Zend_Db_Table_Select)) {
            $select = $this->select();
 
            if ($where !== null) {
                $this->_where($select, $where);
            }
 
            if ($order !== null) {
                $this->_order($select, $order);
            }
 
            if ($count !== null || $offset !== null) {
                $select->limit($count, $offset);
            }
 
        } else {
            $select = $where;
        }
 
        $rows = $this->_fetch($select);
 
        $data  = array(
            'table'    => $this,
            'data'     => $rows,
            'readOnly' => $select->isReadOnly(),
            'rowClass' => $this->_rowClass,
            'stored'   => true
        );
 
        // Here's where it gets interesting
        if ($select->getPart(Zend_Db_Select::LIMIT_COUNT) || $select->getPart(Zend_Db_Select::LIMIT_OFFSET)) {
            // Limit exists, reset unnecessary parameters and columns and re-issue query returning the count
            $select->reset(Zend_Db_Select::LIMIT_COUNT)
                   ->reset(Zend_Db_Select::LIMIT_OFFSET)
                   ->reset(Zend_Db_Select::ORDER)
                   ->reset(Zend_Db_Select::COLUMNS)
                   ->columns('COUNT(1)');
 
            $data['total'] = (int) $this->_db->fetchOne($select);
        }
 
        @Zend_Loader::loadClass($this->_rowsetClass);
        return new $this->_rowsetClass($data);
    }
}
?>

That’s it! I opted to reiterate a large chunk of Zend_Db_Table_Abstract::fetchAll() simply because we’d have to build the Zend_Db_Table_Select object anyway so why do it twice.

When you create your table objects, extend MoreCowbell_Db_Table_Abstract instead of Zend_Db_Table_Abstract. You can then use your table object as usual with the added bonus of if you issue a limit query that returns a resultset, you now have access to the total number of matches. Here’s a quick example.


class My_Table extends MoreCowbell_Db_Table_Abstract
{
    protected $_name = 'my_table';
 
    protected $_primary = 'id';
}
?>


 
$table = new My_Table;
 
$select = $table->select()->where('status = ?', 'NEW')
                          ->limit(10, 20);
 
// Returns rows 21 through 30
// In this example we'll assume there are 50 'NEW' rows present
 
$rows = $table->fetchAll($select);
 
$count = $rows->count(); // 10
$total = $rows->total(); // 50
 
?>