Mirmo Dynamics

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

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).

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:

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.

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:

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.

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.

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).

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 :-)

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.