Zend Framework University

In his recent post Adam Jensen is presenting his approach to creating cron jobs in Zend Framework without having to load entire MVC infrastructure.

Now, any cron task we might envision will most likely need access to a fully-bootstrapped instance of the application; that way we’ll be able to use all of the framework’s usual development conveniences. However, loading the full MVC architecture is a bit of overkill, since we’re going to be performing the same basic sequence of tasks every time the script is hit (see Matthew Weier-O’Phinney’s recent discussion of service APIs for some other relevant concerns). So, we’re going to need a new application bootstrap and entry point, one that eschews the MVC routing and dispatch process in favor of something simpler. Essentially, all we’ll need is to be able to run an arbitrary collection of cron “task plugins,” the list of which can be configured in plain text via any of the various Zend_Config formats (e.g., the default application.ini file).

Adam’s solution is a “framework” or “environment” for developing and running cron jobs. He created cron service to handle execution of tasks, a cron job interface and a plugin infrastructure and shows us how to use it to write simple cron task.

Zend_Acl is usually presented as a tool for restricting access to controllers and actions. It is one of most common use cases of the component, but the component itself can control access to any kind of resource. Adam Jensen wrote interesting post about implementing models as Zend_Acl resources to define access control rules on business logic level.

As a result of these concerns, I decided on a lower-level, model-centric approach for this blog: my models are my resources. Each model class implements Zend_Acl_Resource_Interface, and the ACL specifies “create,” “read,” “update” and “destroy” privileges for each class (more or less). This is a nice paradigm, because it allows for access control at a much lower level: instead of restricting access to the user interface (the controller layer), we restrict access to the business logic (the model layer). (It also makes dynamic assertions a lot more useful, for reasons I may explain some other time.)

In his quick tutorial he shows how to Doctrine_Record_Listener to add ACL to models and make it flexible.