Digital Fashion - zend framework

Zend Framework 1.5.1 PEAR package is available

Geoffrey — Mon, 31 Mar 2008 17:08:00 +0200

A little late sorry, but ZF 1.5.1's package is now ready.

Zend Framework 1.5 PEAR package is available

Geoffrey — Sat, 22 Mar 2008 18:19:00 +0100

The long awaited 1.5 version of the Zend Framework has landed for some days already, and here comes its pear package. Please note the api version changed to 1.5 in this package.

Zend Framework 1.0.4 PEAR package is available

Geoffrey — Wed, 27 Feb 2008 11:17:00 +0100

The package for the last 1.0.x release, 1.0.4, is now available on the phpmafia pear channel. Please report any issue in the comment of this post. The Zend_Locale's xml bug should now be fixed (they are now considered as php and thus put at the right place, which is not the best way to fix the bug I guess but at least it should work for now).

Zend Framework 1.0.3 PEAR package

Geoffrey — Wed, 02 Jan 2008 23:50:00 +0100

Just to say I packaged the 1.0.3 version of the zend framework on the phpmafia pear channel. It's a bit late I know, but at least it's here. Please note that I already have been notified of a problem regarding the Zend Locale's xml datafiles and that I hope to have worked out a solution for the next release (1.5 if all goes well).

Accessing raw post data in a controller

Geoffrey — Wed, 21 Nov 2007 12:03:00 +0100

For some reason, $HTTP_RAW_POST_DATA does not seem to be set inside an action controller. You'll have to use the php://input stream wrapper to access raw http post data:

$raw_post_data = file_get_contents('php://input');

Extending Zend_Controller_Router_Route: the singleton problem.

Geoffrey — Mon, 05 Nov 2007 14:37:00 +0100

Today I ran into an issue while extending Zend_Controller_Router_Route. I wanted to add a little path pre/post processing in the match() and assemble() methods, so I just extended the Route class to add my tiny bits of code into the methods. Except it did not work at all. After a few debuging, it turned out that the Router uses Zend_Controller_Router_Route::getInstance() to retrieve a route object, which uses a new self(); statement to instantiate the route object. Problem is that self always refers to the current class definition we're in, if the method is called from a child class, without being overloaded, self will refer to the wrong class.

Example:

class Foo {

        public static function getInstance() {

                return new self;

        }

}



class Bar extends Foo {}



var_dump(Bar::getClass());

echoes something like:

object(Foo)#1 (0) {
}

Which is fscking wrong IMHO. A quick workaround is to overload the getInstance method, which is what I call pretty annoying as it does not follow the DRY principle.

How I use the Zend Framework

Geoffrey — Mon, 22 Oct 2007 13:39:00 +0200

Having started a few applications using the Zend Framework, I came out with a few practices that I tend to use over and over. In this post I'll quickly expose some of them and explain why I do things the way I do them. As you'll notice, most of them are already widely known and used over the ZF developer's community. Please remember that these practices are just what I do, and come with no garanty at all to be best practices.

Directory structure

First thing to work out when starting a new Zend Framework powered application, at least if you decide to use the ZF's MVC component, is the application's directory structure. Here is the one I used, which is a slightly modified version of the official recommended structure. This is essentially a standard modular structure with all directories needed to store various additional data from your application.

application/
	cache/
	config/
		application.ini
		routes.ini
	data/
	layouts/scripts/
	library/App/
	logs/
	modules/
		default/
		user/
document_root/
	css/
	images/
	index.php
	js/

As you can see, I have many directories, each dedicated to a specific file type. This has many advantages, such as always knowing where to find what you're looking for or easily process files of a certain type (think grep foo logs/*). Also, I name my directories explicitly. I used to call the config directory etc, which is the directory holding most configurations files under UNIX systems, but it may not appear that clear to non-UNIX user, while config is clear enough for everyone.

Another point you might notice is the that all applications files and data are placed outside the document_root. This is done to avoid unwanted access to such resources. While this is the best way, in my opinion, to do, it may not always be possible (like when you have no control on your actual DocumentRoot. In this case, you may consider having the following structure:

application/
	cache/
	config/
		application.ini
		routes.ini
	data/
	layouts/scripts/
	library/App/
	logs/
	modules/
		default/
		user/
	tasks/
css/
images/
index.php
js/

Then you can deny any web access to the application/ directory with the following htaccess rules:

<Directory application>
    Order allow,deny
    Deny from all
</Directory>

Did you say modular ?

Yeah, I said it actually. Modules in Zend Framework are groups of controllers (along with their corresponding views and models) which sits in their own namespace. One could argue that module's primary goal is to ease code re-use, but I personnaly dunno, as I personnally still have not seen such a use of modules. The drawbacks of re-usable code is that it needs to be abstract enough to fit ant particular situation or so. In this context, I only have a single separate module alongside the default one: the user module. It has Index and Auth controllers, respectively used to perform CRUD and login/logout operations.

Having re-usable modules implies that all modules containes its own models, or at least, knows where (ie, in which other module) to find its required models. There comes Xend's model loader. This is an action helper which ease the load of models inside controllers, like:

$this->_helper->modelLoader(array('MyCoolModel', 'MyOtherModel'));

Easy heh ? The bad point with this helper is that it is restricted to, or at best tricky to use outside, action controllers. That is why I developped my own library loader which I shall present in another blogpost soon.

Models naming convention

Using the Xend's model loader trained me to adopt what I consider a good model naming convention, basically, it just follows the controller's conventions, that is, prefix the model name with the module's name, so that for example my user model is named like User_Users (the first User is the module name, the second Users is the ucfirst'ed tablename). whenever I need to have row specific model I just postfix the whole model name with _Row. It gives the following directory architecture:

modules/user/models/
	Users/Row.php
	Users.php

I'll eventually load User_Users_Row from User/Users.php with a simple require:

require_once dirname(__FILE__).'/Users/Row.php';

Personal library namespace

A recurring question from ZF beginners is to know where they should put their own library classes. The answer is pretty simple actually. You just create your own library namespace alongside Zend's. Let's say you wish to extend Zend_Db_Table_Abstract to add your own logic. The first thing to do is to choose the name of your namespace, we will use Foobar as an example, because this is a cool name. Your class will be named like Foobar_Db_Table_Abstract, and located in Foobar/Db/Table/Abstract.php, which in turn should be located anywhere in your include_path. So you could have the following directory structure:

application/library/
	Zend/
	Foobar/
	Riskle/

Just remember ZF's naming convention: from the filename, strip the .php, replace slashes (/) with underscores (_), and you've got the class name. Simple heh ?

App_ library namespace (App_Controller_Action, etc)

Additionnaly to my personal library namespace, I also have a special App namespace, which I always locate into application/library/App. This namespace principally provides two classes, App_Controller_Action and App_Db_Table_Abstract, which basically extend respectively Zend_Controller_Action and Zend_Db_Table_Abstract. All my controllers and models then use the App_ namespace as a reference, so that I can easily change the base class for all my controllers / models as easily as changing the parent of the corresponding App class.

Using third party components

Using ZF compatible components is just easy as dropping them in your include path. By ZF compatible, I mean following the ZF class naming convention. Just make source it's in your include_path, and you can start using them right away. Components library I use includes:

Xend's layout component
Some components from Naneau's library
My own library, Riskle (you'll need an assembla account)

I put them in a particular path (~/share/php/) which I add to my include path.

note: Some dikdiks tend to store third-party in application/library/ instead of a completely separate place. This problem looks a lot like dynamically linked vs static binaries. With static binaries (in our case, storing all in application/library/), you don't have to care about dependencies, as every single needed line of code is shipped with your application. This ease redistribution and installation a lot, but makes your download larger. You also have to manage yourself dependencies upgrade (which in turn save this hassle from the end-user). With dynamically linked applications, you avoid duplicated code by forcing the use of a global, site wide, code repository (generally /usr/share/php on unix systems). You also transfer dependencies handling to the end-user (and/or the packaging system). Really, this is a choice to make yourself I think.

Things get a little bit more complicated when the components does not follow the naming convention. What I do in this case is just puting them into a separate directory tree called vendor/, which I don't forget to add to my include path of course, then I just manually includes need files. We could have done a one-to-one match between the component's public classes and custom well-named classes, but it's much of a hassle for the benefit I think.

That's all folks !

Well that's all for today. I'll try to write some more in the future about application building with the Zend Framework, there are still a lot of things to be said, invented, and discovered :-)

New home for pagination component documentation

Geoffrey — Mon, 01 Oct 2007 12:44:00 +0200

For those caring, I just posted some quick documentation for the pagination component at my assembla space. More docs will follow (including extensive phpdoc docblocks I hope).

Zend Framework 1.0.2 PEAR package is available

Geoffrey — Sun, 30 Sep 2007 16:21:00 +0200

A PEAR package for the 1.0.2 version of the Zend Framework is now available from the PEAR PHPMafia channel. As usual, to install just issue the following:

pear channel-discover pear.phpmafia.net

pear install phpmafia/Zend

Bugfixes release of Zend Framework pagination component

Geoffrey — Sun, 30 Sep 2007 01:28:00 +0200

I just released on riskle's assembla space a new version of my pagination component for the Zend Framework which you can download right now:

Riskle Paginate r122

This release fixes a nasty bug in Riskle_Db_Table::fetchCols which prevented from retrieving the right count of cols involved in the query.

The table component has also been slightly rewritten following Erik's suggestion to move the parent mapping into _fetch. The parent mapping itself has been improved to allow "multi level" table joining. This will be best explained with an example:

Say you have three table, Foo, Bar and Quux, and you would like to execute the following query:

SELECT * FROM Foo JOIN Bar ON Foo.bar_id = Bar.id JOIN Quux ON Bar.quux_id = Quux.id

This is now possible with the following mapping (in Foo's class of course):

array(

    'Bar' => array('local' => 'bar_id', 'remote' => 'id'),

    'Quux' => array('local' => 'quux_id', 'remote' => 'Quux.id'),

);

Easy heh ?

As usual, any comments are appreciated, and please note that this code is released under the same license as the ZF itself, the new-bsd license.

Of controller plugins and directory layout

Geoffrey — Sun, 23 Sep 2007 00:55:00 +0200

When anyone on #zftalk ask about where controller plugins should be kept, we usually responds something like have your own library namesapce alongside Zend/ and put it in it like YourNamespace/Controller/Plugin/YourPlugin.php. But what about application specific controllers ? There's a time where you have to write a plugin that relies on the application at such a level that using it elsewhere would make no sense. In that case, where can we store this plugin ? The question arised this morning, and we ended up to the fact that having a controller-level plugin directory would not hurt, after all. So one could have the following directory layout (simplified on purpose):

/application/modules/default
    /controllers
    /library/Plugin
        MyPlugin.php

The drawback is that in order to use autoload you would have to have each modules Plugin dir in the include path, which is a bit of a hassle. Instead, we could have the much more simple folloing layout:

/application
    library/Controller/Plugin
        MyPlugin.php

Which is simpler but does not allow for modules specific plugins. Anyway, the former layout would require a bit more logic in the bootstrap in order to extract every modules path as plugins are registered pre-dispatch.

Hope it helps with directory layout organization :-)

UPDATE

What I've finally decided to do is the following:

/application
    library/App/Controller/Plugin
        MyPlugin.php

So that application specific code gets prefixed with the App_ namespace.

Zend Framework Pagination, third strike

Geoffrey — Sun, 23 Sep 2007 00:07:00 +0200

UPDATE: new version (r105) available.

The component was given a little rewrite as expected, but maybe a little bit later than I would have wanted to :-) So it now has its own Rowclass proxy from which you can pull various infos such as current page, page range, next page, etc all exposed as getter methods (that is, getCurrentPage, getPageRange, getNextPage, etc), which you won't really have to worry about since the brand new view helper will take care of that for you. Usage has changed a little, bit, so let's first have a look at what's happening from the controller point of view:

$table = new Riskle_Db_Table_Paginate(new Table, $this->_getParam('page'));

$this->view->rowset = $table->fetchAll();

Not much changed here, except we don't need anymore to call getPaginationInfos(). Nice ! Now the big part, the view:

$this->paginate($this->rowset);

echo $this->paginate()->previous();

echo $this->paginate()->navigation();

echo $this->paginate()->next();

The view helper uses the neat composite helper trick from naneau - which is a really cool trick, great job naneau my fellow no-more-a-bunny. The first call inits the helper, feeding him the necessary rowset to work on, then you just have to call the methods you need to draw the navigation links. As you may expect, previous and next method will return nothing if no page is available (actually, they return their second argument, which defaults to an empty string).

Also, it's worth noting that the bundled Riskle_Db_Table features the patch from Erik, as well as a totally rewritten fetchCols method (now uses a straight Zend_Db_Select object instead of the ugly trick it used to use).

My code is no longer available on subversion, I moved the project to assembla. Instead ou can download this component from the riskle space's files board (direct download), the file contains all classes needed for the component to work, just unzip it in your include_path and you're set.

As usual, any comments are more than welcome.

Riskle_Form, a quick wrapup

Geoffrey — Wed, 19 Sep 2007 16:12:00 +0200

So well, I've been busy these days working on my own implementation of a form component in the ZF spirit. This post is to help me see where I'm at with this component, as well as planning future evolution. I'll try my best to describe what it does and does not, and what it could do in the future.

Of course, while this is more of a personnal pense-bete than anything else, any comments are welcome.

Basic features

Forms are build using the factory, which ensures each form has a unique name so that two forms can't conflict when used on the same action. Each element of the form is materialized by an instance of Riskle_Form_Element which holds any configuration directive for the element.

Prototyping

The component features an extensible prototyping system via the Riskle_Form_Prototype set of class. Default (and mandatory atm) is to use a Zend_Config_Ini file which can in turn contains further prototyping instructions, such as prototype from a model (by model I mean a class extending Zend_Db_Table). A given form can embed multiple prototypes, possibly of the same type, which have to be conretized before the form is usable. Concretization of form operates in a FILO merging fashion. Prototyping from a model is for the moment very basic, it treats all fields as text field, but this will be addressed in time. Of course, the system allows for different source of prototyping (think Riskle_Form_Prototype_Xml for example).

Form elements

Elements features a variety of configuration directives, which I'll details here.

type: explicitly tells the type of the field (for the moment, better tell an existing HTML type). default is text.
label: basically, the string to be put into the <label /> tag.
validators: an array of validators, see Data validation for details.
allow_empty: weither the field is allowed to be empty or not.
datasource: specify a datasource to retrieve the field datas from (only used for <select /> fields). See below for further details about that.
depends: specify a field to which the current field is dependent. Mainly used for auto-ajax-refreshing <select />.

The datasource directive deserves a little more explanation. When the form factory encounters a datasource directive, it delegates the work to the datasource factory, which autodetects and decode the datasource. The core distributions handles the following datasources:

Instanciated Model, with format: YourModel->method
Static Model, with format: YourModel::method
CSV string, with format: csv:foo,bar. It uses a user land CSV decoder that will most likely be bundled with the core distribution when (if ?) released.
JSON string, with format: json:{'foo', 'bar'}. It's worth noting that this example will be converted to the following associating array: array('foo' => 'foo', 'bar' => 'bar'). You can avoid this by including a noassoc switch (so that it reads json:noassoc:{'foo', 'bar'}. Another note on JSON: the main problem when allowing JSON in INI files is that you can't have a double quote character in values (except by using a dirty hack which I do not want), and the php json decoder expects identifiers to be doublequoted. The datasource handles this by replacing any non escaped single quote to a double quote.

Data validation

Data validation is done by a subclassed Zend_Input_Filter. validators configuration from elements should conform to ZFI syntax. The custom Riskle_Form_Input component features a getRaw set of methods to retrieve raw data (used in case the form was not successful). Not much else to say here.

Rendering

The core distribution features a set of view helper aimed at easing html form drawing. The helpers use the built-in ZF view helpers to render fields while adding a bunch of custom markup around (namely: labels and error messages). The default helpers also take care of fields that depend on other fields (see Form elements) and add the according ajax queries to populate the element.

Workflow control

The most interesting part I think. Riskle_Form features a plugin system, much like the Zend_Controller one. It exposes the following hooks (in this order):

formStartup, always run at the beginning of the workflow
prePopulate, run before the form gets it data (either from the model or the request)
postPopulate, run after the form gets it data
preValidate, run before the forms attempts to validate the data
onValidateSuccess, run if and only if the data validation was a success
onValidateFailure, run if and only if the data validation was a failure
postValidate, run after the forms attempts to validate the data (regardless of the success or not)
preCommit, run before the form tries to feed the model with the data
onCommitSuccess, run if and only if the data feedage was a success
onCommitFailure, run if and only if the data feedage was a failure
postCommit, run after the forms tries to feed the model with the data (regardless of the success or not)
formShutdown, always run at the end of the workflow

For each hook, the instance of the current form is passed as an argument to the method. Of course, the commit set of hooks will only be run if the data validates.

Sample usage

A simple uploading form could look like the following:

$form = Riskle_Form::factory(new Zend_Config_Ini('upload.ini', null));

$form->registerPlugin(new Riskle_Form_Plugin_Upload('myUploadField'));

$form->run();

$this->view->assign('form', $form);

the view would look like:

echo $this->drawForm($this->form);

and upload.ini could look like:

[form]

model = "uploaded_files"

prototype = 1



[fields]

myUploadField.type = "file"

myUploadField.label = "choose an image"



legend.type = "text"

legend.label = "Legend"

What it lacks

Clearly, this form component is designed for use in an HTML component. Few or no care has been taken to ensure cross-medium compatibiliy such as XHTML, PDF, etc. Hopefully the changes to apply to achieve such compatibility will not be that much of a hassle. While I'm not willing to ensure such a compatibility, I'd be happy to apply any patch submitted.

Regarding plugins, they still miss the ability to really act on the workflow, such as stopping it, skipping steps (?) or add errors to the stack, etc.

Also, the code still needs a few refactoring and optimization, especially regarding the view helpers and the main form class, as well as the configuration file syntax which needs an in-depth revision.

findBy{$Field} with Zend_Db_Table

Geoffrey — Tue, 14 Aug 2007 14:01:00 +0200

A quick post to show how one can easily implement a findByField wrapper in Zend_Db_Table:

/**

         * Implements a simple findByField wrapper

         */



        public function __call($method, $args) {

                if (preg_match('/^findBy([a-zA-Z0-9]+)$/', $method, $parts)) {

                        $field = strtolower(preg_replace('/([a-z])([A-Z])/', '$1_$2', $parts[1]));

                        if (!in_array($field, $this->_cols)) {

                                throw new Zend_Db_Table_Exception(sprintf('\'%s\' field not in row', $field));

                        } else {

                                $db = $this->getAdapter();

                                $where = $db->quoteInto($db->quoteIdentifier($field).' = ?', $args[0]);

                                return $this->fetchAll($where);

                        }

                }

        }

What it does is basically trapping any non-existant method call and check if the corresponding field exists, after converting CamelCasing to underscore_notation (eg: FooBar becomes foo_bar).

Zend_Db_Table and tables relationships

Geoffrey — Mon, 13 Aug 2007 15:39:00 +0200

When developping a database tied application, you eventually come to a point where you get (at least) two tables with a parent/child relationship, such as for example a User table referenced by, say, a Post table (each post belonging to a specific user). That's basically the point where you need Zend_Db_Table relationships mechanism. the drawback of this mechanism is that, as far as I know, it does not produce joined queries to retrieve the parent data, but fires a query for each parent row. Thus instead of just using Zend_Db Relationships, I developped a simple yet effective auto-join mechanism that I called, in great simplicity, parent mapping. It supports multiple joins from multiple tables, remote fields specification and prefixing.

It is included in my db table class and you can see the interesting part of the code below for your convenience (Ignore the 3 first lines of the function as it is used for something else in my version of the framework).

/**

         * Holds the parent mapping for join in fetchAll

         *

         * <code>

         * array(

         *      'remote_table' => array(

         *           'remote' => 'id'

         *           'local' => 'remote_id',

         *           'fields' => array('foo', 'bar', 'prefix' => 'remote_'),

         *      ),

         * );

         * </code>

         *

         * @var array

         */



        protected $_parentMap = array();



        /**

         * Honors the parent mapping from self::_parentMap

         *

         * @param string|array $where

         * @param string|array $order

         * @param integer $count

         * @param integer $offset

         * @return Zend_Db_Table_Rowset

         */



        public function fetchAll($where = null, $order = null, $count = null, $offset = null) {

                if (!is_array($this->_cols)) {

                        return parent::fetchAll($where, $order, $count, $offset);

                } else {

                        $db = $this->getAdapter();

                        $select = $db->select();

                        $select ->from($this->_name, $this->_cols, $this->_schema)

                                        ->order($order)

                                        ->limit($offset, $count);



                        if (!is_null($where)) {

                                $select->where($where);

                        }



                        if (!empty($this->_parentMap)) {

                                foreach($this->_parentMap as $parentTable => $specs) {

                                        $fields = array();

                                        if (isset($specs['fields']['prefix'])) {

                                                $prefix = $specs['fields']['prefix'];

                                                unset($specs['fields']['prefix']);

                                                foreach($specs['fields'] as $key => $field) {

                                                        if (is_int($key)) {

                                                                $key = $prefix.$field;

                                                        }

                                                        $fields[$key] = $field;

                                                }

                                        } else {

                                                $fields = $specs['fields'];

                                        }

                                        $select->join(

                                                $parentTable,

                                                sprintf('%s.%s = %s.%s',

                                                        $db->quoteIdentifier($this->_name),

                                                        $db->quoteIdentifier($specs['local']),

                                                        $db->quoteIdentifier($parentTable),

                                                        $db->quoteIdentifier($specs['remote'])

                                                ),

                                                $fields

                                        );

                                }

                        }



                        $stmt = $db->query($select);

                        return $this->_makeRowset($stmt);

                }

        }

Stripping the logic: the Transfer Object

Geoffrey — Sat, 11 Aug 2007 11:56:00 +0200

Sometimes you have to pass an object data to another object, or to another layer of your application (who said controller/view ?), while ensuring that the receiving entity will not be able to run business code encapsulated in your class. In the Zend Framework, several objects provide a toArray method, but that is not always sufficient as sometimes you'd like to keep with the $object->varname syntax.

That is where the Transfer Object arrives. While the preceding definition is not exact (that's not the real purpose of the Transfert Object in the J2EE spirit), This is the most common use that PHP Developers can make of it nowadays I think. So I came up with a very light implementation of a concept which I hope can prove useful for any folks getting by there.

Zend Framework Pagination reloaded

Geoffrey — Tue, 31 Jul 2007 11:33:00 +0200

UPDATE

A new version of this component is available.

I have a new version of my pagination component which solve the issue previously pointed out by Guy. This update comes along with a subclassed version of Zend_Db_Table which allows counting and specific columns selection respectively via the fetchCount() and fetchCols() methods. Btw, the fetchCols() method is very hackish at the moment, and I'll certainly end up with rewriting it using a plain Zend_Db_Select statement.

As always, any comment is appreciated. I'm thinking of subclassing the Rowset class to fill it with pagination info getters like getPageCount(), getNextPage(), etc, like in Symfony for those knowing, instead of relying on a getPaginationInfo() method. Future improvements will also include more view helper magic.

Also, I came up with a small new Riskle_Pattern namespace which I use to implement commonly used patterns, such as the Proxy Pattern. I'm not yet sure of the pertinence of this thing, so any comments are yet again very much appreciated on this topic :-)

Searching the Zend Framework's manual: Google Co-op to the rescue

Geoffrey — Thu, 19 Jul 2007 12:02:00 +0200

While the Zend Framework's manual is somewhat quite good, it lacks a feature that make it a really good manual: search. I find it very frustrating to not be able to make a simple search and therefor having to browse through the extensive TOC to find what I'm actually looking for. Here enters the very handy Google co-op service which allows creation of custom search engines based on Google's indexes. It do not takes more than five minutes to setup a simple search engine, thus providing search capability to the manual :-)

And as a good news never comes alone, I also made the OpenSearch plugin for it.

UPDATE

I made a simpler url to remind of: http://zend.riskle.com/search/ and updated the opensearch thing to use that url.

Pagination with the Zend Framework

Geoffrey — Sun, 15 Jul 2007 11:38:00 +0200

Yesterday I came up with a small pagination component for the Zend Frameworks. It implements the Proxy pattern around a Zend_Db_Table object, and overloads the fetchAll method. The main problem I encountered here was to retrieve the total number of rows for the table. I'm using a Zend_Db_Select query for now, but I'll have to improve that. The component also features a view helper to draw the pagination links.

You'll find the code for the component and the view helper on my SVN.

And here is how it is used in the controller:

    public function indexAction() {
        $urls = new Riskle_Db_Table_Paginate(new Urls, $this->_getParam('page'));
        $this->view->urlsList = $urls->fetchAll(null, 'datetime DESC');
        $this->view->paginationInfos = $urls->getPaginationInfos();
    }

The view helper takes paginationInfos as an argument:

echo $this->paginate($this->paginationInfos);

UPDATE

As pointed out by Guy, the _getPageCount method does not actually takes care of the $where condition, thus rendering the class inefficient as getting the real totel number of items. This issue will be adressed in an upcoming version of the class :-)

UPDATE

There's an updated version of this component available.

A Zend controller plugin to enable RESTful behaviour

Geoffrey — Sat, 14 Jul 2007 13:33:00 +0200

This is a simple controller plugin for the Zend Framework which enable RESTful behaviour. It basically adds the HTTP method name to the action name, so that the URL http://example.com/foo/bar will be dispatched to FooController::barGetAction on a GET, FooController::barPostAction on a POST, etc.

Here is the actual code:

<?php

class My_Controller_Plugin_Rest extends Zend_Controller_Plugin_Abstract {

        /**
         * Defines the format of the REST action name
         * Quite useless atm as the dispatcher will strip
         * any non alpha character
         */

        protected $_nameFormat = ':action:method';

        /**
         * Rewrites the action according to the http method
         */

        public function preDispatch() {
                $request = $this->getRequest();
                $restActionName = $this->_translateSpec($this->_nameFormat, array(
                        'action' => $request->getActionName(),
                        'method' => $request->getMethod(),
                ));
                $request->setActionName($restActionName);
        }

        /**
         * Inject values into a spec strings
         *
         * Allowed values are:
         *      :action => the action name
         *      :method => the http method
         *
         * @param string $spec
         * @param array $vars
         * @return string
         */

        protected function _translateSpec($spec, $vars = array()) {
                foreach($vars as $key => $value) {
                        switch($key) {
                                case 'action':
                                case 'method':
                                        $$key = $value;
                                break;
                                default:
                                break;
                        }
                }

                $replacements = array(
                        ':action' => $action,
                        ':method' => $method,
                );

                $value = str_replace(array_keys($replacements), array_values($replacements),$spec);
                return $value;
        }
}

Still, i'm not completly satisfied with this plugin. Plugins certainly allows for powerful control over what's going up in the dispatch process, but the dispatcher itself enforces a set of rules on actions naming (eg, you can't have a _ in it, it is stripped at dispatch time). Thus, I'm wondering on the pertinence of writting a custom dispatcher (read My_Controller_Dispatcher_Rest) instead of just a plugin, which would enable far more possibilities.

Btw, in case you're wondering, the plugins is used like this;

$frontController = Zend_Controller_Front::getInstance();
$frontController->registerPlugin(new My_Controller_Plugin_Rest);

Easy heh ?

Also, I'm not convinced that this plugin is the way to go in matter of RESTful functionnality. I'm still wondering if it would not be better to have urls mapped to a single controller, replacing actions with http methods (that is, http://example.com/foo/bar would map to FooController::getAction, etc).

Any opinions around ?