patrickburke.de

Wieder zum Zend Framework.

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.

Heute stand ich vor dem Problem, jedem der Module einer Zend Application eine eigene layout.phtml zuweisen zu müssen. Zuerst dachte ich, es sei ganz einfach über eine application.ini Zeile á la

admin.resources.layout.layoutPath = path/to/layout

möglich (wobei “admin” hier der Modulname ist). Doch wie so häufig brachte der Druck auf F5 Ernüchterung, es funktioniert so nicht.

Eine kurze Google Suche ergab, dass man sich einfach ein Front Controller Plugin schreiben kann, das vor dem Dispatchen abhängig vom Modulnamen die entsprechende layout.phtml lädt. Eigentlich genau das was ich wollte, aber es musste doch einen Weg geben ohne zusätzlichen Code dasselbe Ziel zu erreichen.

Also gab ich mich nicht mit diesem Plugin zufrieden und probierte herum, bis mir eine Fehlermeldung die Augen öffnete. Und zwar sucht Zend unter anderem auch im /scripts/views/ Unterverzeichnis eines jeden Moduls nach einer layout.phtml. Also brauchte ich nur die “resources.layout.*” Einstellungen in der Konfiguration entfernen und eine layout.phtml in den eben genannten Verzeichnissen erstellen und – voilà – schon benutzt jedes Modul sein eigenes Layout; krass, oder?

Mein favourite in Sachen Templates entwickelt sich weiter!

Ihr könnt in der Smarty Developers Group auch euren Senf dazu geben oder in der Smarty Discussion Group einfach mal so über diese tolle Template Engine plaudern.