Zend Framework Blog

Bei der zweiten Abstimmung für die Zend Framework Fragestunde, wurde diese Frage mit 29% der Stimmen auf Platz 1 gewählt: Wo platziere ich am besten meine Validatoren und Filter, im Controller, im Formular oder im Model? Setze ich dabei Zend_Filter_Input ein? Es hat ein wenig gedauert (mehr als zwei Monate), bis ich nun endlich dazu gekommen bin, mich dieser Frage anzunehmen. Dies hatte mehrere Gründe, denn ich war sowohl beruflich als auch privat sehr eingespannt. Bin ich eigentlich immer noch, aber heute habe ich mir die Zeit genommen. Sonst wird die Fragestunde auch eher langweilig und wieder schnell vergessen.

Ein Grund, weshalb die Antwort so lange auf sich warten liess, war auch, dass diese Frage auf den ersten Blick gar nicht so leicht zu beantworten ist. Der Frage ist schon zu entnehmen, dass es viele Möglichkeiten gibt. Werden die Validatoren und Filter im Controller, im Formular oder im Model platziert? Verwendet man lieber Zend_Form oder Zend_Filter_Input? Ich werde hier nun zwei Lösungswege vorstellen, möchte aber auch darauf hinweisen, dass es weitere sinnvolle und gute Lösungen gibt. Und eigentlich ist die Frage auch etwas ungenau gestellt. Denn das Platzieren der Validatoren und Filter ist relativ klar. Unklar ist eher, wann und wo das Filtern und Validieren ausgeführt wird. Doch dazu gleich mehr.

Ansatz 1: Zend_Form zum Filtern und Validieren verwenden

Es ist nahe liegend, für das Filtern und Validieren von Eingabedaten Zend_Form zu verwenden. Diese Komponente bietet bereits alles, was man braucht. Es ist recht einfach, einem Formular beliebige Filter und Validatoren zuzuordnen. Dies ist auch meiner Meinung nach gut im Referenzhandbuch für Zend_Form erläutert, so dass ich dies hier nicht wiederholen möchte. Auch im Quickstart findet sich ein Beispiel. Komplizierter ist aber die Frage, wo in einer Anwendung die isValid() Methode einer Zend_Form Instanz aufgerufen wird.

Als erstes bietet sich der Einsatz im Action-Controller an. Dies ist auch nahe liegend, da der Controller unter anderem auch für die Verarbeitung und Weitergabe der Eingabedaten zuständig ist. Ein Model oder gar eine Formularinstanz sollte nie direkt auf die Daten zugreifen, die über den Request des Benutzers eingehen. In der Regel könnte solch ein Abfrage mehr oder minder wie im folgenden Beispiel aussehen. Es wird eine Instanz des Formulars erstellt, dann wird geprüft, ob das Formular gültig ist. Falls ja, wird erst die Instanz des Models erstellt und dann kann wie in diesem Beispiel ein neues Passwort für einen Benutzer erstellt werden.

Diese Verwendung ist nahe liegend und sieht auf den ersten Blick auch solide aus. Und es funktioniert auch soweit ganz gut. Das Problem ist nur, was man macht, wenn ein Formular z.B. an verschiedenen Stellen einer Anwendung zum Einsatz kommt. Dann muss in der jeweiligen Aktionsmethode des Action-Controller diese Prüfung laufend wiederholt wird. Ich denke da an den Ansatz der "thin controller and fat models" und möchte die Aktionsmethoden so einfach wie möglich halten. Deshalb möchte ich die eigentliche Prüfung der Daten lieber aus dem Controller heraus in das Model verlagern.

Dies hat auch den Vorteil, dass die Prüfung der Daten auch gewährleistet ist, falls ein Model einen neuen Datensatz anlegen soll, der nicht über ein Web-Formular in der Anwendung landet (z.B. beim Importieren von Daten aus einer externen Quelle). Und es macht keinen Sinn, die Prüfung der Eingabedaten redundant im Controller und im Model zu implementieren.

Zuerst schauen wir uns den Ausschnitt aus dem Model an. Es erstellt eine Instanz des Formulars und überprüft die Korrektheit der Daten, wenn das Formular abgeschickt worden ist. Wenn die Eingaben korrekt ware, wird ein neues Passwort erstellt und gespeichert, danach wird eine Mail mit dem Passwort versandt. Wenn dies nicht geklappt hat oder das Formular nicht versandt wurde, wird die Instanz des Formulars zurück gegeben.

Als nächstes schauen wir uns den Action-Controller an. Hier wird nun nicht mehr die Instanz des Formulars, sondern die des Models erstellt. Es gibt eine spezielle Methode für das Erstellen eines neuen Passworts. Diese gibt entweder ein true oder eine Formularinstanz zurück.

Wir verwenden nun also das Zend_Form Objekt innerhalb unseres Models und der Action-Controller muss sich um fast nichts mehr kümmern. Nur die Weiterleitung und die Übergabe an den View sind noch für ihn zu erledigen.

Ansatz 2: Zend_Filter_Input zum Filtern und Validieren verwenden

Verzichtet man aus welchen Gründen auch immer auf den Einsatz von Zend_Form, kann man das Filtern und Validieren alternativ auch von Zend_Filter_Input erledigen lassen. Die Funktionsweise ist im Referenzhandbuch erklärt, so dass ich mir die Einführung von Zend_Filter_Input an dieser Stelle sparen möchte.

Der Einsatz innerhalb eines Models ist aber recht schnell dargestellt. Die Unterschiede zum Einsatz von Zend_Form sind marginal.

Da ich selber Zend_Form sehr gerne und viel einsetze, habe ich Zend_Filter_Input noch nicht so häufig in der Praxis eingesetzt. Aber es ist durchaus möglich, wie das Beispiel zeigt.

Fazit

Das Filtern und Validieren von Eingabedaten ist im Model meistens am besten aufgehoben. Ob man nun Zend_Form oder Zend_Filter_Input einsetzt, bleibt einem selbst überlassen. Beides ist möglich.

Wenn es Fragen gibt oder ihr dies oder jenes völlig anders macht, stehen dafür nun die Kommentare bereit. Ich freue mich auf euer Feedback!

Bei der ersten Abstimmung für die Zend Framework Fragestunde, wurde diese Frage mit 37% der Stimmen auf Platz 1 gewählt: Wie setze ich eine ACL für eine Modul basierte Applikation um?

Hierfür müssen wir als erstes die Grundlage schaffen und festlegen, was eigentlich mit einer Modul basierten Applikation gemeint ist. Das Zend Framework bietet schon seit einen frühen Anfängen die Möglichkeit, eine Applikation in Module aufzuteilen. In einem Modul können somit Action-Controller, View-Skripte, Models, Formulare und mehr gekapselt werden. Die Klassen dieser Module bekommen einen eigenen vorangestellten Namensraum, damit es nicht zu Namenskonflikten kommen kann. Eine Zend Framework Applikation könnte somit aus den Modulen Gästebuch, Forum und CMS (für Ausgabe von Textbeiträgen) bestehen. Zusätzlich zu diesen Modulen gibt es in der Regel immer ein Default-Modul, dass sich unter anderem um die Auslieferung der Homepage kümmert. Zusammenfassend werden wir also mit den folgenden Module arbeiten:

• default
• guestbook
• forum
• cms

Um mit Zend_Acl eine ACL (Access Control List) umsetzen zu können, benötigen wir noch die Benutzerrollen. Wir verwenden an dieser Stelle die drei Benutzerrollen admin, editor und guest und gehen davon aus, dass in allen Modulen die selben Benutzerrollen verwendet werden sollen. Den Aspekt der Wiederverwendbarkeit der Module lasse ich an dieser Stelle bewusst unberücksichtigt. Denn dies würde das Ganze nur noch komplizierter machen.

Als nächstes müssen wir noch überlegen, wie wir die Ressourcen, Privilegien und Rechte in unserer ACL definieren. Hierbei gibt es verschiedene Ansätze. Wir könnten als Ressourcen unsere Models betrachten und deren Methoden als Privilegien einsetzen. Ein anderer Ansatz basiert auf dem Dreigespann Modul, Controller und Action. Diesen Ansatz möchte ich hier vorstellen. Als Privilegien verwenden wir die Namen der Aktionsmethoden und als Ressourcen die Namen der Action-Controller Klassen. Und wo bleibt das Modul? Ganz einfach, für jedes Modul erstellen wir eine eigene ACL. Dies hat auch den Vorteil, dass die ACL insgesamt nicht zu groß wird. Zudem können wir durch geschicktes Cachen der Zend_Acl Objekte zusätzlich die Performance steigern.

Hier folgt als Beispiel die ACL für unser CMS Modul. Die ACLs für die anderen Module sehen ähnlich aus und tragen die Klassennamen Default_Acl, Guestbook_Acl und Forum_Acl.

Das ist keine große Sache und sollte jedem klar sein, der sich mit der Zend_Acl Komponente schon ein wenig befasst hat. Jetzt bleibt die Frage, wann wird die entsprechende ACL denn geladen. Dies kann erst passieren, nachdem das Routing statt gefunden hat und klar ist, welches Modul gerade aufgerufen wird. Dafür verwenden wir ein Plugin.

Das Plugin kümmert sich nur um die Benutzerrechte und nicht um die Authentifizierung. Es geht davon aus, dass diese bereits erfolgt ist. Das Plugin in an sich ist relativ selbsterklärend, hervorheben möchte ich nur, dass auf Basis des aktuellen Moduls der Klassenname der entsprechenden ACL erstellt wird. Der Rest sollte Routine sein. Wenn eine Benutzer nicht über entsprechende Rechte verfügt, wird er als Gast gebeten sich einzuloggen und als angemeldeter User bekommt einen entsprechenden Hinweis.

Das war es schon im Wesentlichen. Das Ganze ließe sich nun noch verfeinern, indem man sich z.B. eine Factory Methode schreibt, welche das Ermitteln des Klassennamens übernimmt. Dadurch kann die ACL auch außerhalb des Plugins anhand eines Moduls ermittelt werden. Diese Methode könnte My_Acl::factory() heißen, als Parameter $module entgegen nehmen und ein von Zend_Acl abgeleitetes Objekt zurückgeben. Diese Factory-Methode könnte sich dabei auch gleich um das Caching kümmern, so dass die ACLs nicht bei jedem Aufruf neu erstellt werden müssen.

Ich hoffe, die Ausgangsfrage ist somit im Wesentlichen beantwortet. Falls nicht, bitte in den Kommentaren melden. Natürlich auch bei Fragen zu diesem Beitrag.