Als ich mir die Dokumentation zu Zend_Acl durchlas war mein erster Gedanke “Mein Gott, ich soll bei jedem Seiten Aufruf die gesamte ACL Struktur laden? Das kann doch nicht euer Ernst sein.”

Natürlich nicht. Erneut Google zur Hilfe gerufen fand ich schnell einen dynamischen ACL Loader im Wiki des Frameworks. Die Lösung! Funktioniert auch super, doch zickte es ein wenig mit Objekte als Resource/Role IDs, selbst dann wenn diese das Zend_Acl_Resource_Interface bzw. das Zend_Acl_Role_Interface implementierten. Also überschrieb ich die entsprechende Methode einfach und fügte so die fehlenden gewünschten Funktionen hinzu.

Blödsinn! Warum? Ganz einfach: Ich hatte sowieso schon eine eigene Version von Zend_Acl::isAllowed() geschrieben (nicht überschrieben, meine Variante gehört zu einem Plugin das für ACL zuständig ist und nicht von Zend_Acl erbt), welche wiederum Zend_Acl::isAllowed() benutzt um festzustellen, ob Peter nun Zugriff hat oder nicht (Ein Name, den ich ständig als Platzhalter benutze, man kann ihn einfach so schnell tippen. Und nein, meine Passwörter enthalten diesen Namen nicht ).

Jedenfalls lade ich nun innerhalb meiner Variante von Zend_Acl::isAllowed() zuerst alle Rollen und Resourcen nach denen gefragt ist (selbstverständlich mit einer Überprüfung ob diese nicht vielleicht schon geladen sind), besorge mir die Berechtigungsdaten aus der Datenbank, verwende entsprechend Zend_Acl::allow() bzw. -::deny() um die Berechtigungen festzulegen und am Schluß Zend_Acl::isAllowed() um nun endlich herauszubekommen wie es um Peters Berechtigungen bestellt ist. Das ACL Objekt sollte statisch deklariert werden um sicherzugehen, dass das Rad nicht ständig neu erfunden wird.