One potential option is caching the entire, constructed ACL object.
Simply invalidate the cache when any changes are made to ACL, and it will be
rebuilt on next request.
I'm sure you don't need the nitty gritty implementation details.
On 12/02/2009 8:53 AM, Robert Castley wrote:
Hi,
Could someone help me out?
I have Zend_Acl all up and running lovely, but further research shows
that some projects serialize the data and store in a database.
My ACL implementation already uses a database for storing roles,
resources etc. but on each time I see my ACL these calls are made to
the database and I am wondering how to slim this down.
e.g.
SELECT "acl_roles".* FROM "acl_roles" ORDER BY "role_id" DESC
SELECT "acl_resources".* FROM "acl_resources"
SELECT "acl_roles".*, "acl_resources".*, "acl_permissions".* FROM
"acl_roles" INNER JOIN "acl_resources" INNER JOIN "acl_permissions"
WHERE (acl_permissions.resource_uid = acl_resources.uid) AND
(acl_roles.role_id = acl_permissions.role_id)
SELECT "acl_roles".*, "users".* FROM "acl_roles" INNER JOIN "users"
WHERE (users.username = "rwc") AND (users.role_id = acl_roles.role_id)
Obviously if I have a page with a ACL call and then two further Ajax
calls that populate the page that also do ACL calls I get the above SQL
sequence x 3 ... not efficient.
The way I am using ACL in my Application is like so:
/**
* Render Administration dialog
*
* @return void
*/
public function administrationAction()
{
if (!$this->_acl->isUserAllowed('mainMenu', 'administration')) {
$this->_helper->layout->enableLayout();
throw new Exception('Permission denied!');
}
}
Cheers,
- Robert
________________________________________________________________________
This email has been scanned for all known viruses by the MessageLabs Email
Security Service and the Macro 4 plc internal virus protection system.
________________________________________________________________________
