Top listings

Yesterday RC1 of Zend Framework was released. I have been working away using it for several months and I have tried to give back small snippets of code as I went along. I had to do some work on my class that extends the Zend ACL and it reminded me how I like to approach coding as a whole. I am a strong believer in building in functionality that always goes beyond the base requirements. In this vain I always think how I can make every feature extendable beyond its natural life span.

The Zend Framework is written entirely in PHP 5 Object Oriented conventions and is currently versioned at 0.9.3 Beta, with a full Release Candidate coming in the immediate future. PHP 5 is a major upgrade over previous incarnations of Object Oriented programming in PHP, and its one of the main reasons I choose the Zend Framework. The framework is built around modular components that can be used as standalone solutions or in conjunction with other components. In this respect they went to great lengths to make the different components very extendable and portable through the creation of interfaces (another PHP 5 caveat) and making sure the components stay as loosely coupled as possible.

When I wrote the previous part of this review, covering the Registry and Database classes of the Zend Framework, the Framework was still at version 0.9.3 Beta. It has since reached version 1.0.0 Release Candidate, and interestingly enough, most of the changes affect the components I’ll be reviewing this time.

If you are looking for a quick way to get started with the Zend Framework, then you should download this file. This download has a default setup for the Zend Framework, including: * A conventional directory structure * A bootstrap file * A configuration file with 2 stages: production, staging * An error controller * An index controller * etc

Contrary to what my tutorial says, I'm one of those people that doesn't want to have to render my common header and footer templates in every single view script file. I prefer a standard site-wide layout script file that will display the content of the action script files within it. The Zend_Controller_Action_Helper_ViewRenderer action helper is a great bit of code that automates rendering a view template based on which action has been called. This is very useful, but renders the action template, not my layout template. To solve this, I am experimenting with extending the Zend_Controller_Action_Helper_ViewRenderer and overriding it so that it know about my layout template. I also prefer to use the view suffix "tpl.php" for my view scripts, so I've made my class automatically set my preferred view suffix.

Over the last couple of days I safaried through the REST component of the Zend Framework to illmuniate the options to provide a public API for on the framework based applications, using a REST architectural style. As I was unhappy that the Zend Framework REST server per default only responds in POX(Plain old XML), a bend over from XML to the 'fat-free' JSON format was favoured to reduce the client sided parsing effort. The first part of this article will quide you through the creation of the responsive part of a RESTful public API and continue to travel the path to achieve the articles purpose.

Zend_Acl est utilisé pour dire si un objet a le droit de faire une action ou non. Avec Zend_Acl, on va pouvoir dire : "tel internaute a le droit de lire le forum A mais pas d'écrire dedans, alors que dans le forum B il aura le droit de lire et d'écrire des messages".

It's 4:30 AM, and I'm sitting in an airport lounge waiting for a flight to Brussels after accidentally bumping into Zeev and a couple of other guys (Amnon and Matti) from Zend, on their way to a management meeting in the US. Since they had to board, and I'm left all alone and still have an hour or so to pass, I'm going to share a nifty little thing I found in Zend Framework a couple of days ago: A nice and clean way to generate relative links in view scripts.

IPC07 is not over yet, but my talk is - it was quite nice IMHO, I got lots of questions, and ran quite a bit over my time - but since it was the last talk of the day it was Ok I guess. I think that my main goal, which was to show how easy it is to start indexing existing content, was acheived and several people came to me and said they thing Zend_Search_Lucene is one killer component.

One could tweak Zend Framework's Router_Route to meet almost all your routing needs. But what if you want something beyond what that package can offer? You can make your routing dreams come true with making your own custom router, all you need to do is implement Zend_Controller_Router_Route_Interface (that's a mouth full).