Cron tasks in Zend Framework apps

Recently, in a fit of narcissism, I decided that my blog needed to be Twitter-aware; that is, I wanted all my posts to display automatically-generated lists of all Twitter tweets that reference them (via the API). Loading these backtweets is a bit resource-intensive, so I figured it'd be best to offload the work to a scheduled background task (e.g., a cron job).


When is a DELETE not a DELETE?

In my recent post on using Zend_Acl with Doctrine record listeners, I described a way to automate a Doctrine-based application's access control logic based on certain event hooks in Doctrine's record listener system. I still think it's a fairly elegant approach, but as I've been working with it, I discovered one behavior I didn't quite expect.


Using Zend_Acl with Doctrine record listeners

Zend_Acl is a very powerful tool to help manage access control logic, but it can be a bit difficult to determine exactly where and how to use it.

In previous Zend Framework apps I've written, I often handled access control at the level of the controller action. Each action was represented in the ACL as a resource, and the ACL logic was applied by a custom plugin just prior to any action dispatch.