The main classes of CakePHP’s ACL implementation are named ACO and ARO, which are acronyms for the technical terms “access control object” and “access request object”. An access control object is something that gets accessed, whereas an access request object is something that wants to access an access control object.

As those acronyms are probably not that familiar to most (I heard them for the first time with the introduction of the ACL feature), you always have to perform translations when you read/hear “ACO” or “ARO”:

ACO => Access Control Object => term you are familiar with
ARO => Access Request Object => term you are familiar with

After a while you (resp. your brain) will make those translations automatically. However, at the beginning, when you try to grasp CakePHP’s ACL implementation, those translation automatisms are not there yet, which makes the understanding more difficult…

Now compare this with the names used in the Zend framework: Zend_Acl_Resource (= ACO) and Zend_Acl_Role (= ARO). At least to me those names sound quite familiar. They are very similar to the terms I would use in a discussion about authorization. And because of this familiarity, the aforementioned translation process can be omitted.

And so I think it would also make sense for CakePHP to use terms like “resource” and “role” instead of ACO and ARO to make it easier for those who want to learn how the ACL feature works.

Part 1 of this series lays out the scope for the series, introduces the frameworks being examined, covers their installation, and scopes out the first test application you will build.

Part 2 walks you through building the sample application in each of the three frameworks, highlighting their similarities and differences.

Part 3 starts with extending the test application, then deals with exceptions to the rule. All frameworks work well when doing the tasks for which they were designed. Needing to do something the framework wasn’t built to do happens on every project. This article looks at such instances.

Part 4 focuses primarily on Ajax support. The use of Ajax, using native code and third-party libraries, is examined — specifically, how each framework behaves and accepts specific popular libraries.

Part 5 deals with working outside the frameworks. A single task is identified (nightly update script), and the process for accomplishing this task is examined in each framework.

[via guymon]

1. Download the Zend Framework
2. Copy the files from the library directory in the zip file to your app/vendors directory
3. Create a wrapper file in vendors in which you include the components you want to use. In the example below I want to use the Zend_Feed component:

   //app/vendors/zendfeed.php
   <?php ini_set('include_path',ini_get('include_path').PATH_SEPARATOR . dirname(__FILE__));?>
   <?php require_once('Zend/Feed.php'); ?>
   

4. Make the Zend component accessible in your controller with

   vendor('zendfeed');

5. Use the Zend component and have fun ;-)

Thanks go to Miguel Ros and Felix Geisendörfer for their help!