At the end of my recent post on building a cron service for your Zend Framework application, I mentioned a couple of weaknesses in the approach I took. Most notably, my cron service lacked any kind of locking mechanism to prevent cron runs from overlapping.
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 backtweets.com 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).
A couple of days ago I blogged about how Doctrine's SoftDelete behavior can keep other listeners' preDelete() hooks from firing; after a bit of coding this morning, I believe I have a solution.
In my initial setup, I had applied the SoftDelete behavior in the model itself via the following YAML config:
Post: actAs: SoftDelete:
Then, in my Zend_Application bootstrap, I was assigning my ACL listener like so:
One of my projects at work lately has been a searchable index of about 80,000 images, each involving about 20 fields' worth of metadata. It's a Drupal project, so it was pretty easy to set up the appropriate content types, fields, and so forth, but when it came time to set up searching, I made a few regrettable assumptions that cost me a lot of time.
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.
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.
Although I've loved using Wordpress for the duration of this blog, recently I've been working on a custom replacement blog platform that I can host and maintain myself. This probably sounds odd, especially since there are already so many excellent blogging platforms available, but I've pushed ahead with it for a couple of reasons I think most developers will understand:
Following right on the heels of my weekend at DrupalCamp, I've stumbled across a few rather interesting blog posts on how Drupal is perceived in other parts of the PHP development community. Thought I'd post the links and make a few comments here, since the issues being discussed are pretty relevant to my day-to-day work as a web technology guy.
Last night I had the pleasure of attending the November meeting of the DallasPHP user group; I've only attended sporadically so far due to how far away I live, but I decided I definitely needed to go to this one: they were talking about the Doctrine ORM, which is the database library behind this blog, and fast becoming one of my favorite open source tools.
As a sort of proof of concept for the ideas I discussed in my previous post, I've put together the first draft of what could become a very helpful reusable module. With this post, I'd like to introduce my new Zend Framework "content" module, which provides several abstract components for a reusable model layer, along with a concrete framework for building a variety of content types sharing a common database-based persistence layer.