Ralfs Zend Framework und PHP Blog » Tutorial http://www.ralfeggert.de Bloggen über das Zend Framework, PHP und anderes Gedöns Tue, 29 Sep 2009 07:15:44 +0000 http://wordpress.org/?v=2.8.6 en hourly 1 Aktuell: Zend Framework Tutorial pausiert http://www.ralfeggert.de/2007/03/31/aktuell-zend-framework-tutorial-pausiert/ http://www.ralfeggert.de/2007/03/31/aktuell-zend-framework-tutorial-pausiert/#comments Sat, 31 Mar 2007 07:56:53 +0000 Ralf Eggert http://www.ralfeggert.de/2007/03/31/aktuell-zend-framework-tutorial-pausiert/ Derzeit bin ich sehr stark mit Arbeit eingedeckt und kann mich momentan leider nicht um die Aktualisierung des Zend Framework Tutorials kümmern. Unsere Firma Travello GmbH ist derzeit dabei, unsere Reiseportale komplett neu zu überarbeiten. Natürlich auf Basis des Zend Frameworks. Diese Arbeit geht zur Zeit vor und ein Ende ist momentan noch nicht abzusehen.

In letzter Zeit habe ich für das Tutorial viele Supportanfragen und E-Mails von PHP Entwicklern bekommen. Ich schaffe es aber einfach nicht, alle Anfragen zu bearbeiten. Deshalb gibt es Bestrebungen, dass komplette Tutorial an die Community zu übergeben, so dass die Zend Framework Community das Tutorial und das darin erstellte Blog gemeinsam weiter pflegen und voran bringen kann. Dies ist leider auch ein wenig eingeschlafen, was zum großen Teil auch an meinem Zeitmangel liegt. Die Anfänge des Zend Framework Tutorial Brutkastens sind schon zu begutachten, aber noch nicht weit fortgeschritten. Wer Lust hat, das Tutorial umzuziehen und auf den neuesten Stand zu bringen, der kann sich gerne bei mir melden.

Ich hoffe, dass ich in Zukunft wieder ein wenige mehr zum Bloggen kommen, wenn auch nicht für das Tutorial, dann aber doch eher allgemeiner Natur. Schauen wir mal.

]]> http://www.ralfeggert.de/2007/03/31/aktuell-zend-framework-tutorial-pausiert/feed/ 7 Zend Framework Tutorial an die Community übergeben? http://www.ralfeggert.de/2007/01/04/zend-framework-tutorial-an-die-community-uebergeben/ http://www.ralfeggert.de/2007/01/04/zend-framework-tutorial-an-die-community-uebergeben/#comments Thu, 04 Jan 2007 10:18:10 +0000 Ralf Eggert http://www.ralfeggert.de/2007/01/04/zend-framework-tutorial-an-die-community-uebergeben/ Nach gründlicher Überlegung habe ich den Entschluss gefasst, mein Zend Framework Tutorial an die Community zu übergeben. Das soll bedeuten, dass ich das Tutorial nicht mehr alleine pflege, sondern die deutsche Zend Framework Community dabei hilft, ein verständliches und tiefgehendes Tutorial für alle Einsteiger zu schaffen.

Die Gründe für diese Entscheidung sind vielfältig. Allen voran habe ich mit der Zeit gemerkt, dass die Pflege des Tutorials beim Erscheinen neuer Releases einfach zu lange dauert, wenn ich mich darum alleine kümmere. Außerdem hat sich gezeigt, dass ein Blog für solch ein Tutorial doch nicht unbedingt die geeignetste Form darstellt. Zumal auch die Druckversion schon immer zu wünschen übrig lässt. Ich bin mittlerweile der Meinung, dass ein Wiki besser für das umfangreiche Tutorial geeignet ist. Zudem hoffe ich, mit der sich gerade entwickelnden Community beim deutschen Zend Framework Forum einige begeisterte Helfer für die Fortführung des Tutorials zu finden.

Im Grunde werden zwei Dinge benötigt. Zum einen ein Wiki für die Pflege der Tutorial Seiten und zum anderen ein SVN Server für die Verwaltung der Projektdateien, mit dem auch der Code für die einzelnen Kapitel des Tutorials verwaltet werden können, damit jeder sich bei Bedarf den vollständigen Code jedes Kapitels downloaden kann. Die Zend Framework Website bietet mit dem Laboratory und dem Wiki bereits die technischen Voraussetzungen, um das Tutorial von der Community pflegen und fortführen zu können. Es wäre aber auch denkbar, ein eigenes Wiki aufzusetzen. Ein eigener SVN Server wiederum würde meiner Meinung nach weniger Sinn machen.

Ich möchte nun alle Interessierten zur Diskussion einladen,

  • wie man das Ganze gemeinsam umsetzen könnte
  • ob man die vorhandenen technischen Voraussetzungen nutzt
  • ob man eigenen technische Voraussetzungen schafft (halte ich persönlich eher für ungünstig)
  • wer Interesse hat, sich an der Umsetzung zu beteiligen
  • wer ggf. an einer Übersetzung in andere Sprachen (vor allem Englisch) interessiert ist
  • was sonst noch so einfällt

Dazu bitte entweder in den Kommentaren hier im Blog melden oder die Diskussion im Zend Framework Forum nutzen. Ich freue mich auf zahlreiche Meinung.

Natürlich werde ich auch weiterhin am Tutorial mitarbeiten und werde sicher auch neue Teile beisteuern. Aber gerade die Pflege nach einem neuen Release artet sehr schnell in Fleißarbeit aus, wenn z.B. eine Änderung in allen Codepaketen eingepflegt werden muss. Parallel werde ich mich auch mit dem Server Team in Verbindung setzen, wie man das Tutorial und die Codebasis auf der Zend Framework Website integrieren könnte.

]]> http://www.ralfeggert.de/2007/01/04/zend-framework-tutorial-an-die-community-uebergeben/feed/ 13 Zend Framework Tutorial verzögert sich http://www.ralfeggert.de/2006/11/22/zend-framework-tutorial-verzoegert-sich/ http://www.ralfeggert.de/2006/11/22/zend-framework-tutorial-verzoegert-sich/#comments Wed, 22 Nov 2006 08:28:14 +0000 Ralf Eggert http://www.ralfeggert.de/2006/11/22/zend-framework-tutorial-verzoegert-sich/ Einige haben es sicher schon bemerkt: das Zend Framework Tutorial verzögert sich derzeit ein wenig. Die beiden Hauptgründe sind die knappe Zeit und die Änderungen an den MVC Komponenten, die derzeit noch nicht in der Library, sondern nur im Incubator verfügbar sind. Da ich wahrscheinlich alle Tutorial Teile überarbeiten muss, wenn das neue Release mit den MVC Änderungen erschienen ist, halte ich die neuen Teile noch so lange zurück und bitte noch um ein wenig Geduld.

]]> http://www.ralfeggert.de/2006/11/22/zend-framework-tutorial-verzoegert-sich/feed/ 4 Zend Framework Tutorial Sonderausgabe: Update auf Release 0.2.0 http://www.ralfeggert.de/2006/11/09/zend-framework-tutorial-release-02/ http://www.ralfeggert.de/2006/11/09/zend-framework-tutorial-release-02/#comments Thu, 09 Nov 2006 09:59:14 +0000 Ralf Eggert http://www.ralfeggert.de/2006/11/09/zend-framework-tutorial-release-02/ Oops, habe ganz vergessen, diesen Beitrag freizuschalten.

In dieser Sonderausgabe des Zend Framework Tutorials werden wir das TravelloBlog auf das vor wenigen Tagen veröffentliche Release 0.2.0 anpassen. Der ursprünglich geplante zwölfte Teil für das Versenden und Empfangen von Trackbacks wird deshalb um eine Woche verschoben. Das Anpassen der bestehenden Tutorialteile ist durchaus zeitintensiv.

Mit dem Release 0.2.0 gab es einige Neuerungen, auch wenn noch nicht alles direkt in der Library des Zend Frameworks aufgenommen worden ist. Die meisten Änderungen sind erst im Incubator vorhanden, so dass ich in dieser Sonderausgabe nur auf die Änderungen an der eigentlichen Library eingehen werde.

Wichtig: Dieses Tutorial setzt die Zend Framework Preview Version 0.2.0 voraus und kann bei der Verwendung einer aktuelleren Version aus dem SVN unter Umständen nicht zu 100% funktionieren. Des weiteren setzt diese Sonderausgabe voraus, dass du das Tutorial bis einschließlich zum elften Teil durchgearbeitet hast.

Auf Release 0.2.0 updaten

Als erstes musst du dir das aktuelle Release 0.2.0 von der Zend Framework Download Seite herunterladen und es in ein Verzeichnis außerhalb des TravelloBlog Projektes entpacken. Im Verzeichnis "/library/zf" löscht du das Unterverzeichnis "/Zend" und die Datei "Zend.php". Du kannst die Dateien aber auch überschreiben.

In deinem Zend Framework Verzeichnis außerhalb des TravelloBlog Projektes suchst du nun das Unterverzeichnis "/library" und kopierst das Unterverzeichnis "/Zend" und die Datei "Zend.php" in das Verzeichnis "/library/zf". Damit ist das Update schon abgeschlossen.

Zend_Config

Als nächstes starte bitte das TravelloBlog in deinem Browser unter der Adresse "http://travelloblog/". Sofort wird dir eine Fehlermeldung angezeigt:

Call to undefined method Zend_Config_Ini::load() in e:\travelloblog\application\config\settings.php on line 53

Wir sehen sofort, in welcher Datei und in welcher Zeile dieser Datei wir nach dem Fehler suchen müssen. Öffne also die Datei "settings.php" im Verzeichnis "/application/config" und navigiere zu Zeile 53.

Das Erstellen eines Zend_Config_Ini Objektes hat sich mit dem neuen Release deutlich vereinfacht. Statt

Quellcode (klicken)
PHP:
  1. $config = new Zend_Config(Zend_Config_Ini::load($iniFile, $section));

kannst du nun einfach

Quellcode (klicken)
PHP:
  1. $config = new Zend_Config_Ini($iniFile, $section);

schreiben. Schon wurde der Fehler von eben korrigiert. Wenn du dein TravelloBlog im Browser neu aufrufst, taucht aber gleich der nächste Fehler auf.

Zend_Controller_RewriteRouter

Die nächste Fehlermeldung betrifft den Zend_Controller_RewriteRouter und ist ein wenig umfangreicher als die erste:

Argument 2 passed to Zend_Controller_RewriteRouter::addRoute() must be an object of class Zend_Controller_Router_Route_Interface, called in e:\travelloblog\application\config\settings.php on line 71 and defined in e:\travelloblog\library\zf\Zend\Controller\RewriteRouter.php on line 64

Wir erkennen, dass der Fehler wieder in unserer "settings.php" Datei liegt. Dieses Mal jedoch in Zeile 71. Mit dem Release 0.2.0 erwartet Zend_Controller_RewriteRouter nun die Übergabe eines Zend_Controller_Router_Route Objektes statt der reinen Parameterliste wie bisher.

Ändere also die Zeilen

Quellcode (klicken)
PHP:
  1. $router = new Zend_Controller_RewriteRouter();
  2. $router->addRoute('actionroute', ':controller/:action/:id', array('controller' => 'article', 'action' => 'index'));
  3. $router->addRoute('404route', 'filenotfound/', array('controller' => 'index', 'action' => 'filenotfound'));
  4. Zend::register('router', $router);

wie folgt ab:

Quellcode (klicken)
PHP:
  1. $route1 = new Zend_Controller_Router_Route(':controller/:action/:id', array('controller' => 'article', 'action' => 'index'));
  2. $route2 = new Zend_Controller_Router_Route('filenotfound/', array('controller' => 'index', 'action' => 'filenotfound'));
  3.  
  4. $router = new Zend_Controller_RewriteRouter();
  5. $router->addRoute('actionroute', $route1);
  6. $router->addRoute('404route', $route2);
  7. Zend::register('router', $router);

Du kannst die Zend_Controller_Router_Route natürlich auch direkt bei der Übergabe an die addRoute() Methode instantiieren, dann werden die beiden Zeilen nur etwa unübersichtlicher.

Ein Reload des TravelloBlogs in deinem Browser birgt aber gleich den nächsten Fehler. Und zwar steigt der Firefox mit einer Umleitungsschleife aus während der Internet Explorer behauptet, dass die Seite nicht angezeigt werden kann.

Dieses Problem lösen wir, indem wir für den RewriteRouter noch die Rewrite Basis setzen:

Quellcode (klicken)
PHP:
  1. $router = new Zend_Controller_RewriteRouter();
  2. $router->addRoute('actionroute', $route1);
  3. $router->addRoute('404route', $route2);
  4. $router->setRewriteBase('');
  5. Zend::register('router', $router);

Zum Abschluss der Änderungen für den Zend_Controller_RewriteRouter können wir den Bugfix in unserer Funktion getRewriteBase() in unserer "settings.php" Datei nun wieder herausnehmen:

Quellcode (klicken)
PHP:
  1. function getRewriteBase()
  2. {
  3.     $url = Zend::registry('router')->getRewriteBase();
  4.    
  5.     return $url;
  6. }

Das war es schon mit den Änderungen für den Zend_Config_RewriteRouter. Wenn du nun das TravelloBlog wieder in deinem Browser aufrufst, sollte wieder alles funktionieren.

Wenn du das TravelloBlog in einem Unterverzeichnis betreibst, musst du das Setzen der Rewrite Basis entsprechend anpassen:

Quellcode (klicken)
PHP:
  1. $router->setRewriteBase('/travelloblog/public');

Noch einmal Zend_Config

Das nächste Problem ist ein wenig schwieriger zu finden. Lasse dir einmal einen beliebigen Artikel anzeigen und erstelle dann einen neuen Kommentar. Du erhältst mehrere Meldungen, u.a.

Notice: Trying to get property of non-object in e:\travelloblog\application\controllers\CommentController.php on line 41

Notice: Trying to get property of non-object in e:\travelloblog\application\controllers\CommentController.php on line 42

Wenn du den CommentController öffnest, findest du dort folgende Zeilen:

Quellcode (klicken)
PHP:
  1. <?php
  2.         [...]
  3.         $mail->setFrom($config->mail->defaultsender);
  4.         $mail->addTo($config->mail->defaultrecipient);
  5.         [...]
  6. ?>

Es muss sich also auch wieder um ein Problem mit Zend_Config handeln. Wenn du dir die "settings.ini" Datei im Verzeichnis "/application/config" anschaust, siehst du, dass wir die Angaben für den Default Sender und Empfänger nur im Abschnitt "[production]" aber nicht im Abschnitt "[development]" definiert haben. Die Vererbung mit Hilfe des "extends = production" funktioniert ab Release 0.2.0 also nicht mehr.

Für Abhilfe ist aber schnell gesorgt. Ändere in der "settings.ini" die Zeilen

[development]
extends = production

einfach in

[development : production]

um und versuche erneut einen Kommentar zu erstellen. Die Fehlermeldungen sollten alle verschwunden sein.

Weitere Fehler

Weitere Fehler durch das Upgrade auf Release 0.2.0 konnte ich bisher nicht finden. Wenn du weitere Fehler gefunden hast, melde dich bitte in den Kommentaren, dann kann ich diesen Artikel bei Bedarf ergänzen.

Download

Der aktuelle Stand des Tutorials nach dieser Sonderausgabe kann herunter geladen werden. Die Textdateien "empty.txt" in einigen Verzeichnissen habe ich nur angelegt, weil mein Winzip keine leeren Verzeichnisse im Zip Archiv anlegt:

Die Zip Datei enthält nicht die aktuelle Version des Zend Frameworks. Dies musst du bitte selber in das entsprechende Verzeichnis kopieren.

Zusammenfassung

In dieser Sonderausgabe des Zend Framework Tutorials haben wir unser TravelloBlog für das neue Release 0.2.0 angepasst und sämtliche durch das Upgrade aufgetretenen Fehler beseitigt.

Nach dieser Sonderausgabe kommen wir im nächsten Teil des Zend Framework Tutorials dann zu dem sehr spannenden Thema für das Versenden und Empfangen von Trackbacks mit Hilfe von Zend_Http_Client.

]]> http://www.ralfeggert.de/2006/11/09/zend-framework-tutorial-release-02/feed/ 3 Zend Framework Tutorial Teil 11: Nützliche Komponenten Zend_Log und Zend_Mail http://www.ralfeggert.de/2006/10/30/zend-framework-tutorial-zend_log-zend_mail/ http://www.ralfeggert.de/2006/10/30/zend-framework-tutorial-zend_log-zend_mail/#comments Mon, 30 Oct 2006 08:03:59 +0000 Ralf Eggert http://www.ralfeggert.de/2006/10/30/zend-framework-tutorial-zend_log-zend_mail/ Im zehnten Teil vom Zend Framework Tutorial haben wir die Zend_Cache Komponente für das Cachen von Templates und Datenbankabfragen kennen gelernt und in unser Projekt integriert. Wenn du die ersten zehn Teile noch nicht gelesen hast, hole dies bitte schnell nach.

In diesem elften Teil des Zend Framework Tutorials werde ich gleich zwei Komponenten vorstellen. Mit Hilfe von Zend_Mail kannst du auf einfache Weise E-Mails erstellen und versenden und die Komponente Zend_Log ist für das individuelle Erstellen von Logs zuständig.

Wenn du über neue Tutorial Teile informiert werden möchtest, abonniere am besten den Feed dieses Blogs. Dann verpasst du garantiert keinen Teil des Tutorials.

Wichtig: Dieses Tutorial setzt die Zend Framework Preview Version 0.2.0 voraus und kann bei der Verwendung einer aktuelleren Version aus dem SVN unter Umständen nicht zu 100% funktionieren.

Inhaltsverzeichnis

Zend_Mail

Für den ersten Einblick in die Zend_Mail Komponente empfehle ich wie immer natürlich den Blick in das Zend_Mail Kapitel im Zend Framework Manual. Dort erfährst du neben der Funktionsweise des einfachen Versands und dem Versand per SMTP auch alles Wissenswerte über HTML E-Mail, Mailanhänge, das Setzen von zusätzlichen Headern und weiteren Empfängern sowie MIME-Abgrenzung und Zeichensätzen.

Hinweis

Bisher ist die Zend_Mail Komponente nur für den Versand von E-Mails zuständig. An einer Erweiterung auch für den Empfang von E-Mails wird aber bereits gearbeitet.

Die grundlegende Funktionsweise ist recht simpel und leicht zu durchschauen. Hier ein erstes Beispiel (entnommen aus dem Manual):

Quellcode (klicken)
PHP:
  1. <?php
  2. require_once 'Zend/Mail.php';
  3. $mail = new Zend_Mail();
  4. $mail->setBodyText('Dies ist der Text dieser E-Mail.');
  5. $mail->setFrom('somebody@example.com', 'Ein Versender');
  6. $mail->addTo('somebody_else@example.com', 'Ein Empfänger');
  7. $mail->setSubject('TestBetreff');
  8. $mail->send();
  9. ?>

Die Methoden zum Setzen des Textes, des Absenders, des Empfängers und des Betreffs sind leicht nachzuvollziehen. Der Versand erfolgt hierbei über die normale mail() Funktion von PHP.

Für den Versand von E-Mails per SMTP müssen vor dem Erstellen des Zend_Mail Objektes noch folgende Zeilen eingefügt werden (am besten in der Bootstrap Datei oder, in unserem Falle, in der "settings.php" Datei):

Quellcode (klicken)
PHP:
  1. $tr = new Zend_Mail_Transport_Smtp('mail.example.com');
  2. Zend_Mail::setDefaultTransport($tr);

Leider ist es derzeit noch nicht möglich, E-Mail mit SMTP Authentifizierung zu versenden. Wer dies dringend benötigt, sollte sich einmal diesen Patch anschauen, der hoffentlich bald implementiert wird.

Wichtiger Hinweis

Da die Einrichtung eines Mailservers unter Windows XP den Rahmen dieses Tutorials sprengen würde, gehe ich darauf nicht weiter ein. D.h. wenn du Zend_Mail so verwendest, wie hier angegeben, ist es wahrscheinlich, dass keine Mails versendet werden und du somit das Gefühl bekommst, dass Zend_Mail nicht funktioniert. Ich empfehle daher, das Projekt auf einem Server einzurichten, auf dem Mailversand möglich ist

Vorüberlegungen für Zend_Mail

Die sinnvollste Möglichkeit für den Versand einer E-Mail sind nach dem Schreiben eines neuen Kommentars oder nach dem Schreiben eines neuen Artikels. Nach diesen Aktionen könnte sich der Administrator des TravelloBlogs per E-Mail informieren lassen.

Es macht durchaus Sinn, die Standard Empfänger- und Versandadressen für diese E-Mails an einer zentralen Stelle zu speichern. Dafür bietet sich natürlich unsere "settings.ini" Datei im Verzeichnis "/application/config" an:

mail.defaultsender    = travelloblog@my-project.com
mail.defaultrecipient = admin@my-project.com

Da wir für unser Beispiel den normalen Versand und nicht den Versand per SMTP verwenden möchten, sind keine weiteren Arbeiten erforderlich. Falls du doch den SMTP Versand bevorzugst, kannst du in der "settings.php" noch folgende Zeilen hinzufügen:

Quellcode (klicken)
PHP:
  1. $tr = new Zend_Mail_Transport_Smtp($config->mail->defaultsender);
  2. Zend_Mail::setDefaultTransport($tr);

Wie schon erwähnt, ist aber derzeit ein Versand mit SMTP Authentifizierung noch nicht möglich.

CommentController anpassen

Wir möchten uns als erstes per E-Mail über neue Kommentare informieren lassen. Es liegt also nahe, den Versand der E-Mail nach dem Speichern des neuen Kommentars durchführen zu lassen. Das wäre also somit in der Methode saveData im CommentController. Um diese Methode nicht zu unübersichtlich werden zu lassen, führen wir als erste eine neue private Methode sendMail im CommentController ein:

Quellcode (klicken)
PHP:
  1. <?php
  2.     [...]
  3.  
  4.     private function sendMail($data)
  5.     {
  6.         $config = Zend::registry('config');
  7.        
  8.         $mailView = new Zend_View();
  9.         $mailView->setScriptPath($config->framework->view_dir);
  10.         $mailView->assign('comment', $data);
  11.        
  12.         $bodyText = $mailView->render('mail/new_comment.php');
  13.        
  14.         $mail = new Zend_Mail();
  15.         $mail->setBodyText($bodyText);
  16.         $mail->setFrom($config->mail->defaultsender);
  17.         $mail->addTo($config->mail->defaultrecipient);
  18.         $mail->setSubject('New comment');
  19.        
  20. //        $mail->send();
  21.     }
  22.  
  23.     [...]
  24. ?>

Was passiert hier? Zuerst holen wir unser Zend_Config Objekt aus dem Objektspeicher. Für das Erstellen des Mailtextesverwenden wir eine neuen Instanz von Zend_View. Das ist einfacher, als per PHP den Mailtext in einem String zusammen zu basteln. Wenn wir den Mailtext erstellt haben, können wir unser Zend_Mail Objekt erstellen und die verschiedenen Elemente mit Inhalten versehen.

Das abschließende Senden der E-Mail habe ich bewusst auskommentiert. Wenn auf deinem Entwicklungsrechner kein Mailserver installiert ist, bekommst du sonst entsprechende Fehlermeldung. Wenn du aber einen Mailserver verfügbar hast (was unter Unix / Linux wohl der Fall aus, aber damit kenne ich mich nicht besonders aus), dann kannst du die Zeile natürlich wieder einkommentieren.

Damit das aber funktionieren kann, benötigen wir noch zwei Dinge. Zum einen müssen wir in der Methode saveData im CommentController noch die Methode sendMail aufrufen:

Quellcode (klicken)
PHP:
  1. <?php
  2.     [...]
  3.  
  4.     private function saveData($data)
  5.     {
  6.         [...]
  7.        
  8.         if (isset($data['com_id']))
  9.         {
  10.             [...]
  11.         }
  12.         else
  13.         {
  14.             $data['com_date'] = date('Y-m-d H:i:s');
  15.            
  16.             $com_id = $comment->insert($data);
  17.            
  18.             $data['com_id'] = $com_id;
  19.            
  20.             $this->sendMail($data);
  21.            
  22.             $art_id = $data['com_art_id'];
  23.         }
  24.        
  25.         [...]
  26.     }
  27.  
  28.     [...]
  29. ?>

Achte bitte darauf, dass du vor dem Aufruf von sendMail() noch die ID des neuen Kommentars an das Array $data übergibst.

Als nächstes brauchst du noch das Template "new_comment.php", welches du im Verzeichnis "/application/views/mail" anlegst:

Quellcode (klicken)
PHP:
  1. A new comment was saved in the TravelloBlog. Here are the details:
  2. ==================================================================
  3.  
  4. <?php echo $this->escape($this->comment['com_title']) . "\n"; ?>
  5. <?php echo str_pad('-', strlen($this->comment['com_title']), '-') . "\n"; ?>
  6.  
  7. From    : <?php echo (strlen($this->comment['com_nickname'])> 0) ? $this->escape($this->comment['com_nickname']) : "anonymous"; ?>
  8. E-Mail  : <?php echo (strlen($this->comment['com_mail'])> 0) ? $this->escape($this->comment['com_mail']) : "-"; ?>
  9. Homepage: <?php echo (strlen($this->comment['com_homepage'])> 0) ? $this->escape($this->comment['com_homepage']) : "-"; ?>
  10. Date    : <?php echo $this->escape($this->comment['com_date']); ?>
  11.  
  12. Comment:
  13. <?php echo wordwrap($this->escape($this->comment['com_text']), 66, "\n"); ?>
  14.  
  15. ==================================================================
  16. Change: http://travelloblog/comment/change/<?php echo $this->escape($this->comment['com_id']); ?>
  17. Delete: http://travelloblog/comment/delete/<?php echo $this->escape($this->comment['com_id']); ?>
  18. ==================================================================

Die Ausgabe kannst du natürlich nach deinen Wünschen umstricken, aber ich denke, das Prinzip sollte klar sein. Du verwendest halt ein ganz normales PHP Skript für die Erstellung des Mailtextes, welches dann von Zend_View aufgerufen und verarbeitet wird.

Übung 1: Zend_Mail für neue Artikel

Als erste Übung bitte ich dich, auch für neue Artikel eine neue Mail zu versenden. Dafür benötigst du neben dem Mailtemplate natürlich auch wieder eine Funktion zum Versenden der Mail und musst den Versand in die entsprechende Methode im ArticleController aufrufen.

Natürlich kannst du dir auch noch weitere Aktionen überlegen, nach dem du eine Mail versenden möchtest. Dies wäre z.B. auch nach dem Anlegen von Kategorien oder Tags bzw. nach dem Ändern oder Löschen von Artikeln und Kommentaren denkbar.

Zur Kontrolle lade dir den aktuellen Stand des Tutorials runter. Dann kannst du deine Ergebnisse damit vergleichen.

Zend_Log

Auch für die Komponente Zend_Log empfehle ich zuerst den Blick in das entsprechende Kapitel im Zend Framework Manual Dies ist zwar noch recht knapp gehalten, beinhaltet aber schon alle wesentlichen Informationen.

Zend_Log kann im Gegensatz zu den meisten anderen Komponenten des Zend Frameworks nicht direkt instanziert werden. Über statische Aufrufe können aber verschiedene, auch mehrfache Logdateien erstellt werden. Dabei stehen mehrere Adapter für das Speichern der Logdaten in Dateien, in einer Datenbank oder in der Konsole zur Verfügung.

Die Verwendung ist recht einfach. Zuerst muss ein zu erstellendes Log unter Angabe des Adapters registriert werden. Danach kann über eine statische Methode überall, wo es notwendig erscheint, geloggt werden, was das Zeug hält. Dieses Beispiel aus dem Manual verwendet den Datei Adapter:

Quellcode (klicken)
PHP:
  1. // Dateilog registrieren
  2. Zend_Log::registerLogger(new Zend_Log_Adapter_File('/logs/simple.txt'));
  3.  
  4. // einfache Nachricht registrieren
  5. Zend_Log::log('Erste Protokollnachricht.');
  6.  
  7. // schwerwiegenden Fehler registrieren
  8. Zend_Log::log('Ein schwerer Fehler ist aufgetreten.', Zend_Log::LEVEL_SEVERE);

Es lassen sich auch mehrere unabhängige Logs erstellen. Dann wird beim Aufruf von Zend_Log::registerLogger noch ein Name übergeben. Und beim Aufruf von Zend_Log::log muss dieser Name ebenfalls angegeben werden:

Quellcode (klicken)
PHP:
  1. // zwei Logs erstellen
  2. Zend_Log::registerLogger(new Zend_Log_Adapter_File('/logs/framework.txt'), 'Datei');
  3. Zend_Log::registerLogger(new Zend_Log_Adapter_Console(), 'Konsole');
  4.  
  5. // Fehler im Dateilog aufnehmen
  6. Zend_Log::log('Ein schwerer Fehler ist aufgetreten.', Zend_Log::LEVEL_SEVERE, 'Datei');
  7.  
  8. // Fehler im Konsolenlog aufnehmen
  9. Zend_Log::log('Ein schwerer Fehler ist aufgetreten.', Zend_Log::LEVEL_SEVERE, 'Konsole');

Hierbei musst du aber darauf achten, dass du immer eine der möglichen Protokollstufen als zweiten Parameter angibst. Eine Übersicht über die Protokollstufen findest du im Manual.

Vorüberlegung für Zend_Log

Im Gegensatz zu Zend_Mail müssen wir für die Registrierung unseres Logs wieder die "settings.php" Datei bemühen, weil wir dort an zentraler Stelle das Log registrieren können.

Welche Informationen wirklich loggenswert sind, darüber gehen die Meinung weit auseinander. Wichtig ist es z.B. Fehler in einem zentralen Log zu speichern, das der Entwickler bei Bedarf dann genau untersuchen kann.

Da wir uns in unserem Projekt bisher jedoch noch nicht intensiv mit dieser Thematik befasst haben, möchte ich vorschlagen, dass wir alle Änderungen an der Datenbank zentral in einer Datei speichern. Also registrieren wir unser Datenbank Log als erstes am Ende unserer "settings.php" Datei:

Quellcode (klicken)
PHP:
  1. Zend_Log::registerLogger(new Zend_Log_Adapter_File($config->framework->log_dir .'/database.txt'), 'Database');

Natürlich müssen wir dieses neue Verzeichnis auch noch anlegen und in unsere "settings.ini" Datei deklarieren:

framework.log_dir         = /path/to/travelloblog/logs

bzw.

framework.log_dir         = e:\travelloblog\logs

Damit kein Unbefugter auf die Logs zugreifen kann, müssen wir diesen Zugriff über den Webserver einschränken. Dafür brauchst du einfach nur die Datei ".htaccess" aus dem Verzeichnis "/application" in das neue Verzeichnis "/log" kopieren. Das war es dann an Vorbereitungen.

Datenbankänderungen loggen

Wir beginnen damit, die Datenbankänderungen für unsere Artikel zu loggen. Dafür öffne bitte die ArticleController Datei und suche die saveData Methode. Dort fügst du direkt hinter den Schreibzugriffen auf die Datenbank die Zeile für das Loggen der Aktion ein:

Quellcode (klicken)
PHP:
  1. <?php
  2.     private function saveData($data)
  3.     {
  4.         [...]
  5.        
  6.         if (isset($data['art_id']))
  7.         {
  8.             [...]
  9.            
  10.             $row->save();
  11.  
  12.             Zend_Log::log('Article ' . $art_id . ' updated', Zend_Log::LEVEL_INFO, 'Database');
  13.         }
  14.         else
  15.         {
  16.             [...]
  17.            
  18.             $art_id = $article->insert($insertData);
  19.            
  20.             Zend_Log::log('Article ' . $art_id . ' created', Zend_Log::LEVEL_INFO, 'Database');
  21.            
  22.             [...]
  23.         }
  24.  
  25.         [...]
  26.     }
  27. ?>

In der doDeleteAction Methode stellst du dann noch sicher, dass auch das Löschen von Artikel geloggt wird:

Quellcode (klicken)
PHP:
  1. <?php
  2.     public function doDeleteAction()
  3.     {
  4.         [...]
  5.        
  6.         $article->delete($where);
  7.        
  8.         Zend_Log::log('Article ' . $art_id . ' deleted', Zend_Log::LEVEL_INFO, 'Database');
  9.        
  10.         [...]
  11.     }
  12. ?>

Jetzt rufe einmal das TravelloBlog in deinem Browser auf und ändere ein paar Artikel, erstelle einen neuen Artikel oder lösche einen bestehenden. Dein Log sollte dann in etwas so aussehen.

Article 3 updated, INFO
Article 3 updated, INFO
Article 2 updated, INFO
Article 8 created, INFO
Article 8 deleted, INFO

Das war es auch schon. Dir steht mit Zend_Log auf jeden Fall eine gute Möglichkeit bereit, individuelle Logs für dein Projekt einzurichten und zu verwalten. Zum Beispiel wäre es noch denkbar, auch einen Zeitstempel mit zu loggen oder beim Loggen sehr schwerwiegender Fehler zeitgleich eine E-Mail an dem Administrator zu versenden. Der Fantasie sind da fast keine Grenzen gesetzt.

Übung 2: Zend_Log für Kommentare, Tags und Kategorien

Als zweite Übung bitte ich dich, auch für Kommentare, Tags und Kategorien entsprechende Meldungen in das Log zu schreiben. Wenn du möchtest, kannst du für jede Entität auch ein eigenes Log erstellen. Du kannst aber auch alle Datenbankänderungen zentral in einem Datenbanklog speichern.

Zur Kontrolle lade dir den aktuellen Stand des Tutorials runter. Dann kannst du deine Ergebnisse damit vergleichen.

Download

Der aktuelle Stand des Tutorials nach diesem sechsten Teil kann herunter geladen werden. Hier sind auch alle Templates enthalten. Die Textdateien "empty.txt" in einigen Verzeichnissen habe ich nur angelegt, weil mein Winzip keine leeren Verzeichnisse im Zip Archiv anlegt:

Die Zip Datei enthält nicht die aktuelle Version des Zend Frameworks. Dies musst du bitte selber in das entsprechende Verzeichnis kopieren.

Zusammenfassung

In diesem elften Teil des Zend Framework Tutorials haben wir die beiden nützlichen Komponenten Zend_Mail für das Versenden von E-Mails und Zend_Log für das Loggen von Informationen kennen gelernt. Auch wenn Windows Nutzer die Funktionsweise von Zend_Mail auf ihrem lokalen Entwicklungsrechner evtl. nicht zu 100% testen konnten, hoffe ich, dass das Prinzip jedoch klar geworden ist.

Nach diesem etwas kürzeren Kapitel kommen wir im nächsten Teil des Zend Framework Tutorials zu einem sehr spannenden Thema: das Versenden und Empfangen von Trackbacks mit Hilfe von Zend_Http_Client.

Change Log

An dieser Stelle werden Änderungen an diesem Tutorial Teil zusammengefasst, die nach dem Ersterscheinen (30.10.2006) notwendig waren, z.B. durch neuere Versionen des Zend Frameworks oder Änderungen am Konzept des Tutorials oder den Anforderungen an unser TravelloBlog.

  • 05.11.2006: Tutorial für Release 0.2.0 aktualisiert

Navigation

]]> http://www.ralfeggert.de/2006/10/30/zend-framework-tutorial-zend_log-zend_mail/feed/ 15 Zend Framework Tutorial Teil 10: Sinnvoll cachen mit Zend_Cache http://www.ralfeggert.de/2006/10/24/zend-framework-tutorial-zend_cache/ http://www.ralfeggert.de/2006/10/24/zend-framework-tutorial-zend_cache/#comments Tue, 24 Oct 2006 05:18:48 +0000 Ralf Eggert http://www.ralfeggert.de/2006/10/24/zend-framework-tutorial-zend_cache/ Im neunten Teil vom Zend Framework Tutorial haben wir die Zend_Filter Komponente für das Filtern von Benutzereingaben kennen und anwenden gelernt. Zudem hast du in einer umfangreicheren Übung (so hoffe ich zumindest) die Kommentarfunktion für unser TravelloBlog realisiert. Wenn du die ersten neun Teile noch nicht gelesen hast, hole dies bitte schnell nach.

In diesem zehnten Teil des Zend Framework Tutorials werde ich Dir die Komponente Zend_Cache vorstellen, mit der du beliebige Daten cachen kannst. Dabei werden wir uns um das Cachen von Templates sowie Datenbankabfragen kümmern und so die Performance unseres TravelloBlogs stark verbessern.

Wenn du über neue Tutorial Teile informiert werden möchtest, abonniere am besten den Feed dieses Blogs. Dann verpasst du garantiert keinen Teil des Tutorials.

Wichtig: Dieses Tutorial setzt die Zend Framework Preview Version 0.2.0 voraus und kann bei der Verwendung einer aktuelleren Version aus dem SVN unter Umständen nicht zu 100% funktionieren.

Inhaltsverzeichnis

Zend_Cache

Zum Einstieg empfehle ich wie immer als ersten den Blick in das Zend_Cache Kapitel im Manual, in dem die Verwendungsmöglichkeiten von Zend_Cache umfassend beschrieben ist.

Bei der Verwendung von Zend_Cache ist zuallererst zwischen dem Frontend und dem Backend zu unterscheiden. Die Zend_Cache Frontends kümmern sich darum, was gecached werden soll, während sich die Zend_Cache Backends darum kümmern, wie gecached werden soll.

Zend_Cache bietet von Haus aus bereits Frontends für das Cachen von Ausgaben, Funktionen, Objekten, Dateien und kompletten Seiten. Dadurch ist Zend_Cache sehr flexibel gestaltet, so dass du dich nicht nur auf das Cachen von Templates beschränken musst, sondern auch Klassen, Datenbankabfragen oder dynamisch erstellte Dateien bequem cachen kannst.

Auch beim Backend bietet Zend_Cache mehrere Optionen. So können die gecacheden Daten als Dateien, in einer Sqlite Datenbank, in einem Memcache Server oder im Shared Memory gespeichert werden. Während für einige Fällen das Cachen in Dateien sinnvoll und ausreichend ist, wäre in anderen Fällen wiederum das Cachen im Shared Memory sinnvoller.

Für weitere Details empfehle ich noch mal den Blick ins Manual, da das Kapitel über Zend_Cache recht umfangreich ist. Da es dort auch viele Beispiele gibt, spare ich mir diese an dieser Stelle. Nach einigen Vorüberlegungen steigen wir eh gleich direkt in die Anwendung ein.

Vorüberlegungen

Als erstes überlegen wir einmal, welche Daten wir überhaupt sinnvoller Weise cachen wollen. Wenn wir das entschieden haben, machen wir uns darüber Gedanken, wie wir diese Daten cachen möchten.

Als erster Anwendungsfall kommt dir sicherlich das Cachen der Ausgaben, also der Templates in den Sinn. Als Frontend würde sich dafür Zend_Cache_Frontend_Output und als Backend Zend_Cache_Backend_File anbieten.

Ein weitere Anwendungsfall wären Datenbankabfragen, die auf jeder bzw. auf sehr vielen Seiten unseres TravelloBlogs durchgeführt werden. Da würden sich z.B. die Datenbankabfragen für die Navigation oder unsere Tagwolke anbieten. Als Frontend würden sich hierfür Zend_Cache_Frontend_Core anbieten und als Backend würde ich wieder Zend_Cache_Backend_File wählen.

Um unsere Cache Dateien speichern zu können, benötigen wir ein weiteres Verzeichnis. Lege also bitte das Verzeichnis "/public/tmp" an und platziere dort eine .htaccess Datei mit folgendem Inhalt, um eine direkten Aufruf der Cache Dateien über den Browser zu vermeiden:

deny from all

Es macht Sinn, das Verzeichnis auch in unsere "settings.ini" Datei aufzunehmen, damit wir über unser Zend_Config Objekt überall darauf zugreifen können. Deshalb füge in die "settings.ini" noch folgenden Eintrag für das Cache Verzeichnis hinzu:

framework.cache_dir       = e:\travelloblog\public\tmp

Startseite cachen

Als erstes benötigen wir ein Zend_Cache Objekt für das Speichern der Templates in Dateien. Dazu öffne die Datei "settings.php" im Verzeichnis "/application/config" und füge dort folgenden Code ans Ende an.

Quellcode (klicken)
PHP:
  1. <?php
  2. [...]
  3.  
  4. $frontendOptions = array('lifeTime' => 10);
  5. $backendOptions = array('cacheDir' => $config->framework->cache_dir);
  6. $templateCache = Zend_Cache::factory('Output', 'File', $frontendOptions, $backendOptions);
  7. Zend::register('templateCache', $templateCache);
  8. ?>

Wir erstellen also einen Cache unter Verwendung des "Output" Frontends und des "File" Backends. Als Parameter für das Frontend habe ich eine Lebenszeit für den Cache von 10 Sekunden angegeben. Auf einem Produktiv Server sollte dieser Wert natürlich höher gesetzt werden. An das Backend übergeben wir nur das erstellte Cache Verzeichnis.

Hinweis

Natürlich kannst du die Angaben zum Frontend und Backend sowie deren Optionen auch in unserer zentralen Konfigurationsdatei "settings.ini" verwalten und dann beim Aufruf von Zend_Cache::factory() übergeben. Ich habe darauf an dieser Stelle einfach verzichtet.

Widmen wir uns nun dem Cachen unserer Startseite, die wohl am häufigsten aufgerufen werden wird. Öffne also bitte den die Datei "ArticleController.php" und suche dort nach der Methode indexAction. Diese änderst du nun wie folgt ab:

Quellcode (klicken)
PHP:
  1. <?php
  2.     [...]
  3.  
  4.     public function indexAction()
  5.     {
  6.         $this->_cacheId = 'index';
  7.        
  8.         if (!$this->_cacheTpl = Zend::registry('templateCache')->get($this->_cacheId))
  9.         {
  10.             $article = new ArticleModel();
  11.            
  12.             $order  = 'art_cdate DESC';
  13.             $rowset = $article->fetchAll(null, $order);
  14.            
  15.             $data = $rowset->toArray();
  16.            
  17.             $this->_view->assign('title', 'TravelloBlog - List of articles');
  18.             $this->_view->assign('articles', $data);
  19.             $this->_view->assign('subtemplate', 'article/index.php');
  20.         }
  21.     }
  22.  
  23.     [...]
  24. ?>

Als erstes legen wir eine Cache Id fest, unter der unser Template gecached werden soll. Wir speichern diese Cache Id in der Klasseneigenschaft $this->_cacheId ab, damit wir später noch darauf zugreifen können.

Danach versuchen wir die Cache Datei für diese Cache Id zu lesen und in der Klasseneigenschaft $this->_cacheTpl abzulegen. Wenn keine gültige Cache Datei gefunden werden konnte, wird false zurückgegeben und die weiteren Zeilen in der if-Bedingung werden ausgeführt. Falls eine gültige Cache Datei gefunden werden konnte, wird dieser Teil nicht ausgeführt. Das war es auch schon im ArticleController für die Startseite.

Wie du dich sicher noch erinnern kannst, haben wir die Ausgabe unsere Templates an eine zentrale Stelle ausgelagert. Und zwar in den Destruktor unserer Travello_Controller_Action Klasse. Als öffne bitte die Datei "Action.php" im Verzeichnis "/library/zf/Travello/Controller/". Der Vollständigkeit halber erstellen wir zuerst die beiden in der indexAction Methode vom ArticleController verwendeten Klasseneigenschaften $this->_cacheId und $this->_cacheTpl und ändern die Methode __destruct wie folgt ab:

Quellcode (klicken)
PHP:
  1. <?php
  2. abstract class Travello_Controller_Action extends Zend_Controller_Action
  3. {
  4.     [...]
  5.  
  6.     protected $_cacheTpl = false;
  7.    
  8.     protected $_cacheId = false;
  9.    
  10.     protected $_cacheTag = array();
  11.    
  12.     [...]
  13.  
  14.     public function __destruct()
  15.     {
  16.         if (!$this->_cacheTpl)
  17.         {
  18.             $this->_view->assign('navigation', $this->getNavigation());
  19.             $this->_view->assign('tagcloud', $this->getTagcloud());
  20.             $this->_view->assign('lastcomments', $this->getComments());
  21.            
  22.             $this->_cacheTpl = $this->_view->render($this->_template);
  23.            
  24.             if ($this->_cacheId)
  25.             {
  26.                 Zend::registry('templateCache')->save($this->_cacheTpl, $this->_cacheId, $this->_cacheTag);
  27.             }
  28.         }
  29.        
  30.         echo $this->_cacheTpl;
  31.     }
  32. }
  33. ?>

Zuerst wird anhand von $this->_cacheTpl geprüft, ob keine Cache Datei gelesen werden konnte. Falls nicht werden die weiteren Templatevariablen zugeordnet sowie die Ausgabe des Templates an $this->_cacheTpl übergeben.

Danach wird geprüft, ob eine Cache Id gesetzt worden ist und bei Bedarf wird das Template in der Cache Datei für unsere angegebene Cache Id gespeichert. Zum Schluss kann dann einfach $this->_cacheTpl ausgegeben werden, weil dort entweder die gelesenen Cache Daten oder das eben gerenderte Template enthalten ist.

Hinweis

Die bereits eingeführte, aber noch nicht erläuterte Klasseneigenschaft $this->_cacheTag benötigen wir an dieser Stelle eigentlich noch nicht. Der Sinn wird erst im nächsten Abschnitt erläutert.

Bevor wir uns das Ergebnis nun anschauen können, solltest du noch in deinem Haupttemplate einen Zeitstempel einbauen, damit man auch sehen kann, ob das Cachen wirklich geklappt hat. Also öffne die Datei "main.php" im Verzeichnis "/application/views" und ändere den Footer wie folgt ab:

Quellcode (klicken)
PHP:
  1. [...]
  2. <div id="footer">
  3. TravelloBlog 2006 - Last update: <?php echo date('Y-m-d H:i:s'); ?>
  4. </div>
  5. [...]

Danach rufe die Startseite des TravelloBlogs auf. Du siehst unten den Zeitstempel und wenn du die Startseite vor Ablauf der 10 Sekunden erneut aufrufst, sollte sich der Zeitstempel nicht verändert haben. Alle anderen Seiten werden aber noch nicht gecached.

Artikelseite cachen

Durch den Destruktor in unserer Travello_Controller_Action Klasse und durch die beiden Klasseneigenschaften $this->_cacheTpl und $this->_cacheId ist das Einführen des Cachens in allen anderen Aktionsmethoden unserer Controller nur noch ein Kinderspiel. Wir müssen lediglich eine Cache ID festlegen und die Abfrage der Cache Datei einbauen.

Für das Cachen eines Artikels macht es Sinn, in die Cache Id auch die Id des Artikels zu übernehmen. Ändere also als nächstes die showAction Methode im ArticleController wie folgt ab:

Quellcode (klicken)
PHP:
  1. <?php
  2.     [...]
  3.  
  4.     public function showAction()
  5.     {
  6.         $art_id = $this->_getParam('id');
  7.        
  8.         $this->_cacheId = 'article_show_' . $art_id;
  9.        
  10.         $this->_cacheTag = array('article_' . $art_id);
  11.        
  12.         if (!$this->_cacheTpl = Zend::registry('templateCache')->get($this->_cacheId))
  13.         {
  14.             $article = new ArticleModel();
  15.  
  16.             [...]
  17.         }
  18.     }
  19.  
  20.     [...]
  21. ?>

Wir erstellen also als erstes eine Cache Id, indem wir die aktuelle Artikel Id anhängen. Danach wird wieder versucht, eine gültige Cache Datei zu lesen. Schlägt dies fehl, werden die notwendigen Daten gelesen. Um den Rest, also das Rendern des Templates und das Speichern in einer Cache Datei kümmert sich dann wieder der Destruktor in unserer Travello_Controller_Action Klasse.

An dieser Stelle haben wir nun die Klasseneigenschaft $this->_cacheTag belegt und du fragst dich sicherlich nach dem Sinn. Mit Hilfe von so genannten Cache Tags kannst du bestimmte Cache Dateien auszeichnen, um sie später gezielt löschen zu können. Es macht also Sinn, alle Cache Dateien eines Artikels zu löschen, wenn sich dieser Artikel ändert oder wenn er gelöscht wird. Darum kümmern wir uns gleich im nächsten Abschnitt.

Die selben Änderungen führen wir nun auch für die Aktionsmethoden deleteAction durch, welche einen Artikel vor dem Löschen noch einmal zur Kontrolle anzeigt. Auch hier setzen wir den gleichen Cache Tag.

Quellcode (klicken)
PHP:
  1. <?php
  2.     [...]
  3.  
  4.     public function deleteAction()
  5.     {
  6.         $art_id = $this->_getParam('id');
  7.        
  8.         $this->_cacheId = 'article_delete_' . $art_id;
  9.        
  10.         $this->_cacheTag = array('article_' . $art_id);
  11.        
  12.         if (!$this->_cacheTpl = Zend::registry('templateCache')->get($this->_cacheId))
  13.         {
  14.             $article = new ArticleModel();
  15.  
  16.             [...]
  17.         }
  18.     }
  19.  
  20.     [...]
  21. ?>

Das war es auch schon. Mehr Aktionsmethoden im ArticleController benötigen kein Cachen, da es keinen Sinn macht, Formulare zu cachen.

Cache Dateien löschen

Unter bestimmten Voraussetzungen macht es Sinn, bestehende aber noch nicht ungültige Cache Dateien zu löschen. Zur Demonstration ändere bitte einmal die Cache Lebenszeit in der "settings.php" Datei von 10 auf 20 Sekunden. Lasse dir dann einen Artikel anzeigen und füge einen Kommentar hinzu. Es sieht nun so aus, als wenn der Kommentar nicht gespeichert worden wäre.

Als müssen wir nach der Änderung eines Artikels oder nach dem Hinzufügen eines Kommentars alle Cache Dateien für diesen Artikel löschen. Hierbei kommt nun endlich auch der Cache Tag zur Anwendung.

Öffne also nun den CommentController und füge in der saveData Methode vor dem Redirect folgende Zeile ein:

Quellcode (klicken)
PHP:
  1. <?php
  2.     [...]
  3.  
  4.     private function saveData($data)
  5.     {
  6.         [...]
  7.        
  8.         Zend::registry('templateCache')->clean(Zend_Cache::CLEANING_MODE_MATCHING_TAG, array('article_' . $art_id));
  9.         Zend::registry('templateCache')->remove('index');
  10.        
  11.         $url = getRewriteBase() . '/article/show/' . $art_id;
  12.        
  13.         $this->_redirect($url);
  14.     }
  15.  
  16.     [...]
  17. ?>

In der ersten Zeile holen wir uns das Cache Objekt aus dem Objektspeicher, rufen die clean() Methode auf und übergeben den Löschmodus für das Löschen anhand von Tags sowie den Tag selber. In der zweiten neuen Zeile löschen wir den Cache für die Startseite anhand der eindeutigen Cache Id.

Wenn du nun erneut einen Artikel aufrufst und einen Kommentar hinzufügst, wird dieser sofort angezeigt.

Beide Zeilen musst du nun noch in der doDeleteAction Methode vom CommentController hinzufügen, damit auch beim Löschen eines Kommentars der Cache gelöscht wird.

Quellcode (klicken)
PHP:
  1. <?php
  2.     [...]
  3.  
  4.     private function doDeleteAction()
  5.     {
  6.         [...]
  7.        
  8.         $art_id = $row->comArtId;
  9.        
  10.         Zend::registry('templateCache')->clean(Zend_Cache::CLEANING_MODE_MATCHING_TAG, array('article_' . $art_id));
  11.         Zend::registry('templateCache')->remove('index');
  12.        
  13.         $url = getRewriteBase() . '/article/show/' . $art_id;
  14.        
  15.         $this->_redirect($url);
  16.     }
  17.  
  18.     [...]
  19. ?>

Der Vollständigkeit halber müssen wir nun auch im ArticleController noch die Cache Dateien nach der Änderung eines Artikels bzw. nach dem Löschen eines Artikels entfernen. Also füge die beiden Zeilen ebenfalls im ArticleController in den Methoden saveData und doDeleteAction vor dem Redirect ein.

Datenbankabfragen cachen

Jetzt möchten wir noch einen anderen Anwendungsfall betrachten. Und zwar werden bestimmte Datenbankabfragen auf jeder Seite durchgeführt. Dabei handelt es sich um das Lesen der Kategorien für die Navigation, um die Tagwolke und die letzten Kommentare. Es macht durchaus Sinn, diese Daten auch zu cachen, da wir sie sicher nicht bei jedem Seitenabruf neu laden müssen.

Dafür benötigen wir als erstes ein weiteres Cache Objekt, mit dem wir Methodenaufrufe einer Klasse cachen können. Füge also am Ende der "settings.php" Datei folgende Zeilen ein:

Quellcode (klicken)
PHP:
  1. <?php
  2. [...]
  3.  
  4. $frontendOptions = array('lifeTime' => 20, 'automaticSerialization' => true);
  5. $backendOptions = array('cacheDir' => $config->framework->cache_dir);
  6. $dataCache = Zend_Cache::factory('Core', 'File', $frontendOptions, $backendOptions);
  7. Zend::register('dataCache', $dataCache);
  8. ?>

Wir setzen hier die automatische Serialisierung der Daten auf true, damit wir ohne größeren Aufwand auch Arrays speichern können. Die Lebenszeit können wir deutlich höher setzen als bei den Templates, da sich die zu cachenden Daten wie Kategorien meistens noch seltener ändern.

Danach ändere bitte in der Datei "Action.php" im Verzeichnis "/library/zf/Travello/Controller/" die Methode "getNavigation" wie folgt ab:

Quellcode (klicken)
PHP:
  1. <?php
  2.     [...]
  3.  
  4.     private function getNavigation()
  5.     {
  6.         $cacheId = 'data_navigation';
  7.        
  8.         if (!$data = Zend::registry('dataCache')->get($cacheId))
  9.         {
  10.             $category = new CategoryModel();
  11.            
  12.             $order  = 'cat_name';
  13.             $rowset = $category->fetchAll(null, $order);
  14.            
  15.             $data = $rowset->toArray();
  16.            
  17.             Zend::registry('dataCache')->save($data, $cacheId);
  18.         }
  19.        
  20.         return $data;
  21.     }
  22.  
  23.     [...]
  24. ?>

Wir legen wieder eine Cache Id fest und prüfen, ob es eine gültige Cache Datei gibt. Falls nicht, werden die Daten aus der Datenbank gelesen und im Cache gespeichert. Das war es auch schon.

Der Vollständigkeit halber hier die Änderungen für die Methode "getTagcloud":

Quellcode (klicken)
PHP:
  1. <?php
  2.     [...]
  3.  
  4.     private function getTagcloud()
  5.     {
  6.         $cacheId = 'data_tagcloud';
  7.        
  8.         if (!$tags = Zend::registry('dataCache')->get($cacheId))
  9.         {
  10.             $tag = new TagModel();
  11.             $db = $tag->getAdapter();
  12.            
  13.             $select = $db->select();
  14.             $select->from('tag', 'tag.*, COUNT(tag_id) AS tag_count');
  15.             $select->join('art2tag', 'tag_id = art2tag_tag_id');
  16.             $select->order('tag_name');
  17.             $select->group('tag_id');
  18.            
  19.             $tags = $db->fetchAll($select);
  20.            
  21.             Zend::registry('dataCache')->save($tags, $cacheId);
  22.         }
  23.                
  24.         return $tags;
  25.     }
  26.  
  27.     [...]
  28. ?>

Und hier die Änderungen für die Methode "getComments":

Quellcode (klicken)
PHP:
  1. <?php
  2.     [...]
  3.  
  4.     private function getComments()
  5.     {
  6.         $cacheId = 'data_lastcomments';
  7.        
  8.         if (!$comments = Zend::registry('dataCache')->get($cacheId))
  9.         {
  10.             $comment = new CommentModel();
  11.             $db = $comment->getAdapter();
  12.            
  13.             $select = $db->select();
  14.             $select->from('comment', '*');
  15.             $select->order('com_date DESC');
  16.             $select->limit(5);
  17.            
  18.             $comments = $db->fetchAll($select);
  19.            
  20.             Zend::registry('dataCache')->save($comments, $cacheId);
  21.         }
  22.                
  23.         return $comments;
  24.     }
  25.  
  26.     [...]
  27. ?>

Soviel erst einmal zur Zend_Cache Komponente, die auch noch viele weitere Anwendungsmöglichkeiten bietet. Zum Beispiel könnten wir unser Zend_Config Objekt auch in einer Cache Datei ablegen usw.

Übung: Caching für weitere Controller

Als heutige Übung nehme dir bitte den TagController und den CategoryController vor und füge dort auch die Caching Funktionalität hinzu. Achte dabei auch darauf, dass du bei Änderungen alte Cache Dateien löscht. Zudem musst du natürlich auch die Anzeige der 404 Fehlerseite im IndexController cachen. Achte hier aber auf die Ausgabe des 404 Status, der immer ausgegeben werden muss.

Zur Kontrolle lade dir den aktuellen Stand des Tutorials runter. Dann kannst du deine Ergebnisse damit vergleichen.

Download

Der aktuelle Stand des Tutorials nach diesem sechsten Teil kann herunter geladen werden. Hier sind auch alle Templates enthalten. Die Textdateien "empty.txt" in einigen Verzeichnissen habe ich nur angelegt, weil mein Winzip keine leeren Verzeichnisse im Zip Archiv anlegt:

Die Zip Datei enthält nicht die aktuelle Version des Zend Frameworks. Dies musst du bitte selber in das entsprechende Verzeichnis kopieren.

Zusammenfassung

In diesem zehnten Teil des Zend Framework Tutorials haben wir die Zend_Cache Komponente kennen gelernt und unsere erstellten Templates in Cache Dateien gespeichert. Wir haben uns außerdem darum gekümmert, dass Cache Dateien von Artikeln auch gelöscht werden, wenn es neue Kommentare gibt oder der Artikel geändert wird. Zudem haben wir einige Datenbankabfragen gecached, um die Datenbank zu entlasten.

Im nächsten Teil des Tutorials werde ich dir die nützlichen Komponenten Zend_Log für das Erstellen von individuellen Logs sowie Zend_Mail für den Versand von E-Mails vorstellen.

Change Log

An dieser Stelle werden Änderungen an diesem Tutorial Teil zusammengefasst, die nach dem Ersterscheinen (23.10.2006) notwendig waren, z.B. durch neuere Versionen des Zend Frameworks oder Änderungen am Konzept des Tutorials oder den Anforderungen an unser TravelloBlog.

  • 05.11.2006: Tutorial für Release 0.2.0 aktualisiert

Navigation

]]> http://www.ralfeggert.de/2006/10/24/zend-framework-tutorial-zend_cache/feed/ 13 Zend Framework Tutorial Teil 9: Benutzereingaben filtern mit Zend_Filter_Input http://www.ralfeggert.de/2006/10/16/zend-framework-tutorial-zend_filter_input/ http://www.ralfeggert.de/2006/10/16/zend-framework-tutorial-zend_filter_input/#comments Mon, 16 Oct 2006 06:17:34 +0000 Ralf Eggert http://www.ralfeggert.de/2006/10/16/zend-framework-tutorial-zend_filter_input/ Im achten Teil vom Zend Framework Tutorial haben wir die Zend_Config Komponente für das Laden unsere Konfigurationsdaten verwendet, unsere Bootstrap Datei stark entschlackt und noch ganz nebenbei zwei Bugs aus dem siebten Teil bereinigt. Wenn du die ersten acht Teile noch nicht gelesen hast, hole dies bitte schnell nach.

In diesem neunten Teil des Tutorials widmen wir uns nun dem Filtern der Benutzereingaben mit der Zend Framework Komponente Zend_Filter_Input. Bisher haben wir direkt auf die Daten der globalen $_POST Variable zugegriffen, was zwar funktioniert, aber gewisse Sicherheitsprobleme bringen kann. Wir werden die Komponenten auch mit eigenen Methoden erweitern und uns in einer umfangreichen Übung um die Kommentarfunktion für unser TravelloBlog kümmern.

Wenn du über neue Tutorial Teile informiert werden möchtest, abonniere am besten den Feed dieses Blogs. Dann verpasst du garantiert keinen Teil des Tutorials.

Wichtig: Dieses Tutorial setzt die Zend Framework Preview Version 0.2.0 voraus und kann bei der Verwendung einer aktuelleren Version aus dem SVN unter Umständen nicht zu 100% funktionieren.

Inhaltsverzeichnis

Zend_Filter

Bevor wir uns Zend_Filter_Input widmen möchte ich zuerst die Komponente Zend_Filter vorstellen, da Zend_Filter_Input diese Komponente intensiv verwendet. Für eine erste sehr kurze Einführung empfehle ich wie immer den Blick ins Zend_Filter Kapitel im Manual.

Hinweis

Das Kapitel im Manual über die Zend_Filter Komponente ist stark verbesserungswürdig und entspricht nicht mehr ganz dem aktuellen Stand der ZF 0.2.0 Version. So gibt es in Zend_Filter keine Methode testEmail(). Diese heißt isEmail().

Zend_Filter ist im Prinzip eine Bibliothek mit statischen Methoden für das Filtern von Daten. Es stellt dabei drei Typen von Methoden bereit für unterschiedliche Anwendungsfälle beim Filtern von Daten. Hier wird zwischen dem so genannten Whitelist Filtern, dem Blinden Filtern und dem Blacklist Filtern unterschieden.

Beim Whitelist Filtern wird geprüft, ob die zu prüfenden Daten einem bestimmten Format entsprechen. Sind z.B. nicht erlaubte Zeichen enthalten oder entsprechen die Daten nicht dem Format wird "false" zurückgegeben. Andernfalls die korrekten Daten. Beim blinden Filtern werden nur die erwünschten Zeichen zurückgegeben. Und beim Blacklist Filtern wird geprüft, ob die Daten einem bestimmten Format entsprechen, um sie dann auszuschließen.

Hinweis

Noch ein weiterer Hinweis. Die Methoden in Zend_Filter zum Blacklist Filtern sind im eigentlichen Sinne keine Blacklist Filter, sondern auch blinde Filter, weil sie Zeichen entfernen, die nicht in den zu prüfenden Daten vorkommen dürfen.

Leider sind die Methoden im Manual noch nicht ausführlich dokumentiert. Um einen Überblick über die vorhandenen Methoden zu erhalten, empfehle ich entweder den direkten Blick in den Code von Zend_Filter und in die Api Docs. Dort oben rechts das Paket Zend_Filter auswählen, dann rechts auf "Class trees" klicken und danach auf Zend_Filter klicken. Die Methoden, welche mit "get" beginnen, sind die blinden Filter und die Methoden, welche mit "is" beginnen, sind die Whitelist Filter.

Zend_Filter_Input

Die Komponente Zend_Filter_Input setzt auf Zend_Filter auf und stellt einen guten Ansatz für das Filtern von Benutzereingaben bereit. Auch hier wieder der Hinweis auf das Manual, das ein wenig ausführlicher als das Kapitel zu Zend_Filter ist.

Um Zend_Filter_Input zu verwenden, wird eine Instanz erstellt und dabei ein Array mit Benutzereingaben übergeben. In der Regel handelt es sich dabei um die globale $_POST oder $_GET Variable. Hier ein einfaches Beispiel für die Anwendung:

Quellcode (klicken)
PHP:
  1. <?php
  2.     $filterPost = new Zend_Filter_Input($_POST);
  3.    
  4.     if ($alphaName = $filterPost->testAlpha('name')) {
  5.         /* $alphaName enthält nur Buchstaben. */
  6.     } else {
  7.         /* $alphaName evaluiert als FALSE. */
  8.     }
  9. ?>

Nach der Übergabe wird die $_POST bzw. $_GET Variable übrigens auf "null" gesetzt, so dass man fortan nur noch über das Zend_Filter_Input Objekt auf diese Daten zugreifen kann. Es bietet sich also an, ein Zend_Filter_Input Objekt im Objektspeicher abzulegen, so dass man von überall aus darauf zugreifen kann. Möchtest du das "auf null setzen" von $_POST bzw. $_GET vermeiden, musst du an den Konstruktor als zweiten Parameter "false" übergeben.

Leider sind die Methoden von Zend_Filter_Input im Manual ebenfalls noch nicht im Detail dokumentiert. Um einen Überblick über die vorhandenen Methoden zu erhalten, empfehle ich entweder den direkten Blick in den Code von Zend_Filter_Input und in die Api Docs. Dort oben rechts das Paket Zend_Filter auswählen, dann rechts auf "Class trees" klicken und danach auf Zend_Filter_Input klicken. Die Methoden, welche mit "get" beginnen, sind die blinden Filter und die Methoden, welche mit "test" beginnen, sind die Whitelist Filter.

Zend_Filter_Input Objekt erstellen

Um ein Zend_Filter_Input Objekt verwenden zu können, müssen wir es erst erstellen und dann im Objektspeicher ablegen, damit wir uns unseren Controller Klassen auf die Daten zugreifen können. Öffne also nun die Datei "settings.php" im Verzeichnis "/application/config" und füge ans Ende folgende Zeilen ein:

Quellcode (klicken)
PHP:
  1. <?php
  2. [...]
  3.  
  4. $post = new Zend_Filter_Input($_POST);
  5. Zend::register('post', $post);
  6. ?>

Für unser TravelloBlog brauchen wir vorerst nur ein Filter Objekt für die $_POST Daten. Du kannst aber auf die gleiche Weise auch ein Filter Objekt für die $_GET Daten anlegen.

Das war es auch schon und wir können uns direkt ums Filtern der Eingabedaten in unseren Controller Klassen kümmern.

ArticleController ändern

Bisher greifen wir im ArticleController nur in den Methoden validateAction und doDeleteAction auf die $_POST Variable zu. Also müssen wir diese Methoden überarbeiten.

Öffne nun die Datei "ArticleController.php" im Verzeichnis "/application/controllers/" und suche nach der validateAction Methode. Ändere nun die ersten Zeilen wie folgt ab:

Quellcode (klicken)
PHP:
  1. <?php
  2.     public function validateAction()
  3.     {
  4.         $post = Zend::registry('post');
  5.        
  6.         if (!$post->keyExists('button_save'))
  7.         {
  8.             $url = getRewriteBase() . '/';
  9.            
  10.             $this->_redirect($url);
  11.         }
  12.        
  13.         [...]
  14. ?>

Als erstes holen wir uns das Zend_Filter_Objekt zurück aus dem Objektspeicher. Dann prüfen wir, ob der Schlüssel "button_save" vorhanden ist, d.h. ob der Speicherbutton angeklickt worden ist. Falls der Schlüssel nicht vorhanden ist, leiten wir auf die Startseite unseres TravelloBlogs um, um direkte Aufrufe der validateAction Methode zu verhindern.

Als nächstes passen wir den Codeblock an, in dem die übertragenen Daten an unser $data Array übergeben werden, damit diese später gespeichert werden können. Ändere also die folgenden Zeilen wie folgt ab:

Quellcode (klicken)
PHP:
  1. <?php
  2.     public function validateAction()
  3.     {
  4.         [...]
  5.  
  6.         $data = array();
  7.        
  8.         if ($post->keyExists('art_id'))
  9.         {
  10.             $data['art_id'] = $post->getDigits('art_id');
  11.         }
  12.        
  13.         $data['art_title' ] = $post->getRaw('art_title');
  14.         $data['art_teaser'] = $post->getRaw('art_teaser');
  15.         $data['art_text'  ] = $post->getRaw('art_text');
  16.        
  17.         $data['art2cat_cat_id'] = $post->keyExists('art2cat_cat_id')
  18.                                 ? $post->getDigits('art2cat_cat_id')
  19.                                 : null;
  20.        
  21.         $data['art2tag_tag_id'] = $post->keyExists('art2tag_tag_id')
  22.                                 ? $post->getDigits('art2tag_tag_id')
  23.                                 : null;
  24.        
  25.         [...]
  26. ?>

Hier prüfen wir zuerst, ob ein Wert für "art_id" übergeben worden ist, und falls ja, werden alle Zeichen, die keine Ziffern sind, gefiltert. Das heißt also, dass ein Aufruf von Zend_Filter_Input::getDigits() nur Ziffern zurück liefert.

Für die Felder "art_title", "art_teaser" und "art_text" lassen wir uns erst einmal die rohen Daten zurück geben, da wir diese gleich noch detaillierter testen möchten. Für die beiden Felder "art2cat_cat_id" und "art2tag_tag_id" verwenden wir wieder Zend_Filter_Input::getDigits() und sehen, dass die Funktion sogar auf Arrays angewendet werden kann.

Jetzt wird in validateAction schon mal nicht mehr direkt auf die $_POST Variable zugegriffen. Wir können aber die Daten noch weiter prüfen und gegen nicht erwünschte Eingaben prüfen. Dafür ändern wir den nächsten Codeabschnitt nun wie folgt:

Quellcode (klicken)
PHP:
  1. <?php
  2.     public function validateAction()
  3.     {
  4.         [...]
  5.  
  6.         $errors = array();
  7.        
  8.         if (strlen($data['art_title']) == 0)
  9.         {
  10.             $errors['art_title'] = 'Please enter a title!';
  11.         }
  12.         elseif ($post->testRegex('art_title', '=[^[:alnum:]\ \-\.\,\!\?\/]='))
  13.         {
  14.             $errors['art_title'] = 'Only letters, digits, spaces and the following signs allowed: -/.,!?';
  15.         }
  16.        
  17.         if ($post->testRegex('art_teaser', '=[^[:alnum:]\ \-\.\,\!\?\/]='))
  18.         {
  19.             $errors['art_teaser'] = 'Only letters, digits, spaces and the following signs allowed: -/.,!?';
  20.         }
  21.        
  22.         if (strlen($data['art_text']) == 0)
  23.         {
  24.             $errors['art_text'] = 'Please enter a text!';
  25.         }
  26.         elseif ($data['art_text'] != $post->noTags('art_text'))
  27.         {
  28.             $errors['art_text'] = 'No tags allowed!';
  29.         }
  30.                
  31.         [...]
  32. ?>

Für die beiden Felder "art_title" und "art_teaser" führen wir nun eine weitere Prüfung mit Hilfe eines regulären Ausdrucks ein, der auf Buchstaben, Ziffern, Leerzeichen und ausgewählte Satzzeichen prüft. Für das Feld "art_text" prüfen wir zudem, ob HTML Tags im Text vorhanden sind und geben dann eine entsprechende Fehlermeldung aus.

Rufe nun einmal in deinem Browser das TravelloBlog auf und ändere einen Artikel. Gebe dort bewusst Daten ein, welche die Fehlermeldungen hervorrufen sollen und klicke dann auf Speichern. Dies könnte dann in etwa wie folgt aussehen:

Artikel validieren

Das funktioniert also schon einmal sehr gut. Eine Sache ist aber noch ein wenig störend. Wenn wir unseren regulären Ausdruck zum Prüfen von "art_title" und "art_teaser" ändern möchte, um z.B. ein weiteres Zeichen zu den erlaubten hinzuzufügen, müssen wir das schon an zwei Stellen ändern. Verwenden wir den regulären Ausdruck auch in anderen Controllern wird es schnell unübersichtlich.

Du fragst dich nun also sicher, ob du nicht auch Zend_Filter_Input anpassen kannst, um den regulären Ausdruck dort zentral für Prüfungen ablegen zu können. Kannst du, also lies schnell weiter!

Zend_Filter und Zend_Filter_Input erweitern

Um unseren regulären Ausdruck nicht nur in Zend_Filter_Input, sondern auch bei der direkten Verwendung von Zend_Filter verwenden zu können, müssen wir beide Klassen erweitern.

Wir beginnen mit Zend_Filter und erstellen nun im Verzeichnis "/library/zf/Travello" die Datei "Filter.php" mit folgendem Code:

Quellcode (klicken)
PHP:
  1. <?php
  2. class Travello_Filter extends Zend_Filter
  3. {
  4.     public static function isTitle($value)
  5.     {
  6.         return (bool) preg_match('=[^[:alnum:]\ \-\.\,\!\?\/]=', $value);
  7.     }
  8.    
  9. }
  10. ?>

Das war es schon? Ja, das war es schon. Der Name ist vielleicht nicht ganz glücklich gewählt, aber mir ist an dieser Stelle nichts besseres eingefallen. Um diese Methoden nun auch mit unserer Zend_Filter_Input Instanz verwenden zu können, müssen wir auch diese Klasse erweitern.

Erstelle nun also das Verzeichnis "/library/zf/Travello/Filter" und lege dort die Datei "Input.php" mit folgendem Code an:

Quellcode (klicken)
PHP:
  1. <?php
  2. class Travello_Filter_Input extends Zend_Filter_Input
  3. {
  4.     public function testTitle($key)
  5.     {
  6.         if (!$this->keyExists($key)) {
  7.             return false;
  8.         }
  9.         if (Travello_Filter::isTitle($this->_source[$key])) {
  10.             return $this->_source[$key];
  11.         }
  12.  
  13.         return FALSE;
  14.     }
  15. }
  16. ?>

In der Methode Travello_Filter_Input::testTitle() wird zuerst geprüft, ob ein Wert für den Schlüssel vorhanden ist. Danach wird die Travello_Filter::isTitle() Methode aufgerufen und bei erfolgreicher Prüfung der Wert zurückgegeben.

Um unsere erweiterten Klassen verwenden zu können, müssen wir nun die Instantiierung in der "settings.php" Datei entsprechend anpassen:

Quellcode (klicken)
PHP:
  1. <?php
  2. [...]
  3.  
  4. $post = new Travello_Filter_Input($_POST);
  5. Zend::register('post', $post);
  6. ?>

Und zum Schluss passen wir nun noch die validateAction Methode in unserem ArticleController an, indem wir den Aufruf von testRegex() durch testTitle() ersetzen:

Quellcode (klicken)
PHP:
  1. <?php
  2.     public function validateAction()
  3.     {
  4.         [...]
  5.  
  6.         elseif ($post->testTitle('art_title'))
  7.         {
  8.             $errors['art_title'] = 'Only letters, digits, spaces and the following signs allowed: -/.,!?';
  9.         }
  10.        
  11.         if ($post->testTitle('art_teaser'))
  12.         {
  13.             $errors['art_teaser'] = 'Only letters, digits, spaces and the following signs allowed: -/.,!?';
  14.         }
  15.        
  16.         [...]
  17. ?>

Prüfe das Ganze nun noch einmal in deinem Browser und es sollte weiterhin wie gewünscht funktionieren. Du kannst natürlich Travello_Filter und Travello_Filter_Input auch um weitere Methoden für zusätzliche Filter ergänzen.

Da die Methode Zend_Filter::isEmail() derzeit noch nicht implementiert ist, übernehmen wir das nun, da wir eine Prüfung auf eine E-Mail Adresse später noch brauchen werden. Füge also in Travello_Filter nun noch folgende zweite Methode hinzu:

Quellcode (klicken)
PHP:
  1. <?php
  2. class Travello_Filter extends Zend_Filter
  3. {
  4.     [...]
  5.  
  6.     public static function isEmail($value)
  7.     {
  8.         return (bool) preg_match('=^[a-z0-9][\._a-z0-9-]*@[a-z0-9][\.a-z0-9-]*(\.[a-z]{2,6})$=i', $value);
  9.     }
  10. }
  11. ?>

Dies ist natürlich keine, auch nur annähernd perfekte Prüfung auf eine gültige E-Mail Adresse, aber für unsere Zwecke reicht es. Wer Langeweile hat kann gerne RFC 2822 komplett implementieren und den Code dann der Zend Framework Community zur Verfügung stellen.

In Travello_Filter_Input musst du nun noch den Aufruf unser eigenen isEmail Methode einfügen:

Quellcode (klicken)
PHP:
  1. <?php
  2. class Travello_Filter_Input extends Zend_Filter_Input
  3. {
  4.     [...]
  5.  
  6.     public function testEmail($key)
  7.     {
  8.         if (!$this->keyExists($key)) {
  9.             return false;
  10.         }
  11.         if (Travello_Filter::isEmail($this->_source[$key])) {
  12.             return $this->_source[$key];
  13.         }
  14.  
  15.         return FALSE;
  16.     }
  17. ?>

Weitere Controller ändern

Bevor wir uns TagController und CategoryController widmen, müssen wir noch die Abfrage in doDeleteAction wie bei validateAction entsprechen anpassen:

Quellcode (klicken)
PHP:
  1. <?php
  2.     public function doDeleteAction()
  3.     {
  4.         $post = Zend::registry('post');
  5.        
  6.         if (!$post->keyExists('button_delete'))
  7.         {
  8.             $url = getRewriteBase() . '/';
  9.            
  10.             $this->_redirect($url);
  11.         }
  12.        
  13.         [...]
  14. ?>

Auf die gleiche Weise kannst du auch die Methoden doDeleteAction im TagController und im CategoryController anpassen.

Für Tags möchten wir nur Buchstaben, das Leerzeichen und das kaufmännische Und zulassen. Du kannst für diese Prüfung gerne auch eine eigene Methode in Travello_Filter einführen. Die Methode validateAction im TagController ändere also wie folgt ab:

Quellcode (klicken)
PHP:
  1. <?php
  2.     public function validateAction()
  3.     {
  4.         $post = Zend::registry('post');
  5.        
  6.         if (!$post->keyExists('button_save'))
  7.         {
  8.             $url = getRewriteBase() . '/tag/';
  9.            
  10.             $this->_redirect($url);
  11.         }
  12.        
  13.         $data = array();
  14.        
  15.         if ($post->keyExists('tag_id'))
  16.         {
  17.             $data['tag_id'] = $post->getDigits('tag_id');
  18.         }
  19.        
  20.         $data['tag_name'] = $post->getRaw('tag_name');
  21.        
  22.         $errors = array();
  23.        
  24.         if (strlen($data['tag_name']) == 0)
  25.         {
  26.             $errors['tag_name'] = 'Please enter a name for the tag!';
  27.         }
  28.         elseif ($post->testRegex('tag_name', '=[^[:alpha:]\ \&]='))
  29.         {
  30.             $errors['tag_name'] = 'Only letters, spaces and ampersand allowed';
  31.         }
  32.  
  33.         [...]
  34. ?>

Für Kategorien möchten wir nur Buchstaben, Ziffern, den Bindestrich und das Leerzeichen zulassen. Du kannst für diese Prüfung gerne auch eine eigene Methode in Travello_Filter einführen. Die Methode validateAction im CategoryController ändere also wie folgt ab:

Quellcode (klicken)
PHP:
  1. <?php
  2.     public function validateAction()
  3.     {
  4.         $post = Zend::registry('post');
  5.        
  6.         if (!$post->keyExists('button_save'))
  7.         {
  8.             $url = getRewriteBase() . '/category/';
  9.            
  10.             $this->_redirect($url);
  11.         }
  12.        
  13.         $data = array();
  14.        
  15.         if ($post->keyExists('cat_id'))
  16.         {
  17.             $data['cat_id'] = $post->getDigits('cat_id');
  18.         }
  19.        
  20.         $data['cat_name'] = $post->getRaw('cat_name');
  21.        
  22.         $errors = array();
  23.        
  24.         if (strlen($data['cat_name']) == 0)
  25.         {
  26.             $errors['cat_name'] = 'Please enter a name for the category!';
  27.         }
  28.         elseif ($post->testRegex('cat_name', '=[^[:alnum:]\ \-]='))
  29.         {
  30.             $errors['cat_name'] = 'Only letters, digits, spaces and hyphens allowed';
  31.         }
  32.        
  33.         [...]
  34. ?>

Übung: Kommentarfunktion

Die heutige Übung ist etwas umfangreicher als sonst und hat nicht ausschließlich etwas mit den heute vorgestellten Komponente Zend_Filter_Input zu tun. Auch wenn du dabei natürlich Zend_Filter_Input bzw. unsere erweiterte Klasse verwenden sollst.

Bitte implementiere nun die Kommentarfunktion für Artikel und setze dabei diese Punkte um:

  • Ausgabe aller vorhandenen Kommentare bei einem Artikel (ältester oben)
  • Hinzufügen von neuen Kommentaren zu einem Artikel
  • Ändern und Löschen bestehender Kommentare
  • Ausgabe der ersten 40 Zeichen der 5 letzten Kommentaren in der Box 2 auf der rechten Seite (neuester oben)

Diese Übung ist wie gesagt deutlich umfangreicher als die bisherigen Übungen. Da wir aber im letzten Teil sowieso keine Übung dabei hatten und mit dieser Übung noch einmal alles bisher Gelernte angewandt werden muss, ist diese Übung sehr sinnvoll.

Damit du nicht vollkommen verloren bist, hier ein paar Tipps, wie du die Sache angehen könntest:

  • Als erstes brauchst du natürlich eine neue Model Klasse für Kommentare sowie Templates für Kommentare zur Darstellung eines Formulars.
  • Als nächstes musst du den CommentController mit den Methoden buildForm, saveData, changeAction, validateAction, deleteAction und doDeleteAction ausstatten.
  • Dann benötigst du noch zwei Templates: eines zum Anzeigen des Kommentarformulars und eines zum Löschen eines Kommentars.
  • Nach dem Anlegen, Ändern und Löschen eines Kommentars solltest du per Redirect auf den entsprechenden Artikel umleiten, zu dem der Kommentar gehört.
  • Die Anzeige der letzten Kommentare in der Box 2 lässt sich ähnlich wie die Tagwolke erledigen.
  • Zusätzlich könntest du noch ein wenig Hand an unsere CSS Datei anlegen, damit die Ausgabe der Kommentare etwas besser aussieht.
  • Und nicht vergessen die Methode ArticleController::doDeleteAction so anzupassen, dass beim Löschen eines Artikels auch die zugehörigen Kommentare gelöscht werden.

Zur Kontrolle lade dir den aktuellen Stand des Tutorials runter. Dann kannst du deine Ergebnisse damit vergleichen.

Download

Der aktuelle Stand des Tutorials nach diesem sechsten Teil kann herunter geladen werden. Hier sind auch alle Templates enthalten. Die Textdateien "empty.txt" in einigen Verzeichnissen habe ich nur angelegt, weil mein Winzip keine leeren Verzeichnisse im Zip Archiv anlegt:

Die Zip Datei enthält nicht die aktuelle Version des Zend Frameworks. Dies musst du bitte selber in das entsprechende Verzeichnis kopieren.

Zusammenfassung

In diesem neunten Teil des Zend Framework Tutorials haben wir die Zend_Filter und Zend_Filter_Input Komponenten kennen gelernt und für die Prüfung der Eingabedaten durch die Nutzer verwendet. Wir haben die beiden Klassen auch um eigene Funktionen erweitert, so dass wir fortan an ein gutes, zentrales Werkzeug für das Filtern von Benutzereingaben haben.

Im nächsten Teil des Tutorials werden wir uns dem Cachen von diversen Daten kümmern und die Zend_Cache Komponente kennen lernen.

Change Log

An dieser Stelle werden Änderungen an diesem Tutorial Teil zusammengefasst, die nach dem Ersterscheinen (16.10.2006) notwendig waren, z.B. durch neuere Versionen des Zend Frameworks oder Änderungen am Konzept des Tutorials oder den Anforderungen an unser TravelloBlog.

  • 05.11.2006: Tutorial für Release 0.2.0 aktualisiert

Navigation

]]> http://www.ralfeggert.de/2006/10/16/zend-framework-tutorial-zend_filter_input/feed/ 7 Zend Framework Tutorial Teil 8: Konfiguration mit Zend_Config http://www.ralfeggert.de/2006/10/09/zend-framework-tutorial-zend-config/ http://www.ralfeggert.de/2006/10/09/zend-framework-tutorial-zend-config/#comments Mon, 09 Oct 2006 05:23:31 +0000 Ralf Eggert http://www.ralfeggert.de/2006/10/09/zend-framework-tutorial-zend-config/ Im siebten Teil vom Zend Framework Tutorial haben wir uns ein wenig intensiver mit Zend_Controller, Zend_Db und Zend_View auseinander gesetzt und unsere Anwendung navigierbarer und mit Hilfe von CSS auch ein wenige hübscher gemacht. Wenn du die ersten sieben Teile noch nicht gelesen hast, hole dies bitte schnell nach.

In diesem achten Teil des Tutorials widmen wir uns nun einer neuen Komponente. An mehreren Stellen in unserer Applikation haben wir bereits verschiedene Konfigurationsdaten eingeführt. Es macht jedoch sehr viel Sinn, alle Konfigurationsdaten an einer zentralen Stelle abzulegen und von überall aus zugreifbar zu machen. Dabei hilft uns die Komponente Zend_Config. Außerdem werden wir unsere Applikation auch heute noch ein wenig mehr aufräumen und zwei Bugs fixen.

Wenn du über neue Tutorial Teile informiert werden möchtest, abonniere am besten den Feed dieses Blogs. Dann verpasst du garantiert keinen Teil des Tutorials.

Wichtig: Dieses Tutorial setzt die Zend Framework Preview Version 0.2.0 voraus und kann bei der Verwendung einer aktuelleren Version aus dem SVN unter Umständen nicht zu 100% funktionieren.

Inhaltsverzeichnis

Zend_Config

Als Einführung in die Zend_Config Komponente empfehle ich dir, erst einmal einen kurzen Blick in das Zend_Config Kapitel im Manual zu werfen. Dort erfährst du schon ein wenig über die Funktionsweise von Zend_Config.

Für das Einlesen der Konfigurationsdaten stellt Zend_Config mehrere Ladeklassen bereit. So können die Daten aus einem PHP Array, einer .ini Datei oder einer XML Datei gelesen und in einem Zend_Config Objekt für die Anwendung bereit gestellt werden.

Es kann sogar auf so genannte "Sections" zugegriffen werden, um bestimmte Bereiche einer Konfigurationsdatei zu laden. Dadurch können z.B. die Zugriffsdaten für eine Datenbank für die Entwicklung und die Produktion in der selben Datei vorgehalten werden.

Eine beispielhafte .ini Konfigurationsdatei könnte wie folgt aussehen:

[production]
base_url  = /my/base/url

database.type     = pdo_mysql
database.host     = db.example.com
database.username = dbuser
database.password = secret
database.name     = dbname
colours.website.green = 00FF00
colours.website.blue  = 0000FF

colours.navi.green = 00CC00
colours.navi.blue  = 0000CC

[development : production]
database.host     = db-dev.example.com

Das Laden sähe dann wie folgt aus:

Quellcode (klicken)
PHP:
  1. $config = new Zend_Config_Ini('/path/to/config.ini', 'production');

Nach dem Laden der Konfigurationsdaten kann dann sehr einfach auf selbige zugegriffen werden. Dabei sind auch beliebig tiefe Verschachtelungen möglich, wie diese Beispiele zeigen. Außerdem steht die Methode asArray() bereit, um ein Array zurückzugeben:

Quellcode (klicken)
PHP:
  1. echo $config->base_url;
  2. echo $config->database->host;
  3. echo $config->colours->website->green;
  4.  
  5. $database = $config->database->asArray();

Für detailliertere Informationen zu Zend_Config möchte ich nochmals auf das Manual hinweisen.

Eine .ini Konfigurationsdatei erstellen

Als erstes müssen wir einmal schauen, welche Daten sich dazu anbieten, dass sie zentral in einer Konfigurationsdatei abgelegt werden. Primär sind diese Daten bisher in unserer Bootstrap Datei enthalten. Es bieten sich vor allem die verschiedenen Verzeichnispfade, die Datenbankparameter und die Routen an.

Lege also nun im Verzeichnis "/application/config" die Datei "settings.ini" mit folgendem Inhalt an:

[production]
# Settings for the Zend Framework
framework.application_dir = /path/to/travelloblog/application
framework.controller_dir  = /path/to/travelloblog/application/controllers
framework.model_dir       = /path/to/travelloblog/application/models
framework.view_dir        = /path/to/travelloblog/application/views
framework.view_helper_dir = /path/to/travelloblog/library/zf/Travello/View\Helper

# Settings for the database
database.adapter = PDO_MYSQL
database.params.host     = my.host.de
database.params.username = secret
database.params.password = muchmorsecret
database.params.dbname   = travelloblog

[development : production]
# Settings for the Zend Framework
framework.application_dir = e:\travelloblog\application
framework.controller_dir  = e:\travelloblog\application\controllers
framework.model_dir       = e:\travelloblog\application\models
framework.view_dir        = e:\travelloblog\application\views
framework.view_helper_dir = e:\travelloblog\library\zf\Travello\View\Helper

# Settings for the database
database.adapter = PDO_MYSQL
database.params.host     = 127.0.0.1
database.params.username = root
database.params.password =
database.params.dbname   = travelloblog

In dieser Datei habe ich sowohl die Daten für unseren Entwicklungsrechner als auch für den Produktionsserver abgelegt.

Übrigens brauchst du dir keine Sorgen machen, dass jemand fälschlicherweise diese .ini Datei direkt über den Browser anzeigen lassen kann. Dies haben wir durch unsere ".htaccess" Datei im Verzeichnis "/application" bereits ausgeschlossen.

Datei settings.php anlegen

Natürlich können wir die Konfigurationsdaten auch direkt in unserer Bootstrap Datei laden. Ich habe mir jedoch angewöhnt, das Laden von Konfigurationsdaten in eine eigene Datei auszulagern. Das macht die Bootstrap Datei übersichtlicher und eventuelle Sicherheitsprobleme beim fehlerhaften Ausliefern der Bootstrap Datei werden auch umgangen.

Lege also nun im Verzeichnis "/application/config" die Datei "settings.php" mit folgendem Inhalt an:

Quellcode (klicken)
PHP:
  1. <?php
  2. $iniFile = dirname(__FILE__) . DIRECTORY_SEPARATOR . 'settings.ini';
  3. $config = new Zend_Config_Ini($iniFile, 'development');
  4. Zend::register('config', $config);
  5.  
  6. Zend::dump($config->asArray());
  7. ?>

Wir laden also die Daten aus der Konfigurationsdatei "settings.ini" und legen das Zend_Config Objekt im Objektspeicher ab. Danach geben wir zum Testen einmal alle Daten aus.

Da du diese Datei nicht direkt über den Browser aufrufen kannst, müssen wir sie nun noch in unserer Bootstrap Datei einbinden. Öffnen also die Datei "index.php" im Verzeichnis "/public" und ändere sie wie folgt:

Quellcode (klicken)
PHP:
  1. <?php
  2. [...]
  3.  
  4. require_once('set_include_path.php');
  5.  
  6. require_once 'Zend.php';
  7.  
  8. require_once 'settings.php';
  9.  
  10. function __autoload($class)
  11. {
  12.     Zend::loadClass($class);
  13. }
  14.  
  15. [...]
  16. ?>

Wenn du nun das TravelloBlog im Browser aufrufst, sollte oben folgende Ausgabe erscheinen:

array(2) {
  ["framework"] => array(5) {
    ["application_dir"] => string(27) "e:\travelloblog\application"
    ["controller_dir"] => string(39) "e:\travelloblog\application\controllers"
    ["model_dir"] => string(34) "e:\travelloblog\application\models"
    ["view_dir"] => string(33) "e:\travelloblog\application\views"
    ["view_helper_dir"] => string(47) "e:\travelloblog\library\zf\Travello\View\Helper"
  }
  ["database"] => array(2) {
    ["adapter"] => string(9) "PDO_MYSQL"
    ["params"] => array(4) {
      ["host"] => string(9) "127.0.0.1"
      ["username"] => string(4) "root"
      ["password"] => string(0) ""
      ["dbname"] => string(12) "travelloblog"
    }
  }
}

Du kannst gerne auch einmal ausprobieren, was angezeigt wird, wenn du das "development" beim Erstellen des Zend_Config Objektes durch "production" austauscht. Entferne danach wieder die Ausgabe der Konfigurationsdaten aus der "settings.php" Datei.

Bootstrap Datei entschlacken

Wie weiter oben bereits erwähnt, habe ich es mir angewöhnt, die Bootstrap Datei so weit wie möglich zu entschlacken und den Aufbau des Systems bzw. das Anlegen diverser Objekte in die "settings.php" auszulagern.

Entferne also als erstes den Abschnitt für die Definition der Datenbankparameter und das Anlegen des Datenbankadapters aus der Bootstrap Datei. Füge dann an das Ende der "settings.php" Datei folgende Zeilen ein:

Quellcode (klicken)
PHP:
  1. $adapter = $config->database->adapter;
  2. $params  = $config->database->params->asArray();
  3.  
  4. $db = Zend_Db::factory($adapter, $params);
  5. Zend_Db_Table::setDefaultAdapter($db);

Lade das TravelloBlog im Browser neu und es sollte weiterhin wie gewünscht funktionieren.

Als nächstes entferne bitte den Codeblock für das Erstellen des Zend_Controller_RewriteRouter Objektes bis zum Ablegen im Objektspeicher aus der Bootstrap Datei und füge es an das Ende der "settings.php" Datei wieder ein:

Quellcode (klicken)
PHP:
  1. $route1 = new Zend_Controller_Router_Route(':controller/:action/:id', array('controller' => 'article', 'action' => 'index'));
  2.  
  3. $router = new Zend_Controller_RewriteRouter();
  4. $router->addRoute('actionroute', $route1);
  5. $router->setRewriteBase('');  // change to '/travelloblog/public' for subdirectory
  6. Zend::register('router', $router);

Die Konfiguration der Routen könnten wir auch in die "settings.ini" Datei ablegen, jedoch würde das einiges an zusätzlicher Tipparbeit ersparen und das Lesen der Routen verschlechtern. Stattdessen belassen wir es vorerst einmal dabei.

Als nächstes entferne den gesamten Codeblock vom Anlegen des Zend_View Objektes bis zum Ablegen im Objektspeicher aus der Bootstrap Datei und füge ihn leicht abgeändert an das Ende der "settings.php" Datei wieder ein:

Quellcode (klicken)
PHP:
  1. $view = new Zend_View();
  2. $view->setScriptPath($config->framework->view_dir);
  3. $view->addHelperPath($config->framework->view_helper_dir);
  4.  
  5. $baseurl = $router->getRewriteBase();
  6. $view->assign('baseurl', $baseurl);
  7.  
  8. Zend::register('view', $view);

Jetzt sieht unsere Bootstrap Datei schon übersichtlicher aus, doch wir können noch weiter gehen. Bitte entschlacke deine Bootstrap Datei nun soweit, dass nur noch diese wenigen Zeilen enthalten sind:

Quellcode (klicken)
PHP:
  1. <?php
  2. require_once 'settings.php';
  3.  
  4. $controller = Zend_Controller_Front::getInstance();
  5. $controller->setRouter($router);
  6. $controller->setControllerDirectory($config->framework->controller_dir);
  7. $controller->dispatch();
  8. ?>

Die eben entfernten Zeilen füge nun an den Anfang der "settings.php" Datei ein:

Quellcode (klicken)
PHP:
  1. require_once 'set_include_path.php';
  2.  
  3. require_once 'Zend.php';
  4.  
  5. function __autoload($class)
  6. {
  7.     Zend::loadClass($class);
  8. }

Ein erneutes Laden des TravelloBlogs im Browsers sollte dir zeigen, dass weiterhin alles funktioniert. Die Bootstrap Datei ist nun sehr kurz und enthält nur das wesentliche. Das Laden der Konfigurationseinstellungen und das Anlegen aller benötigten Objekte ist nun in der "settings.php" ausgelagert.

Die gesamte settings.php Datei

Es macht nun eigentlich keinen großen Sinn mehr, für das setzen des "include_path" eine eigene Datei vor zuhalten, so dass du als nächstes die Codezeilen aus der Datei "set_include_path.php" an den Anfang der "settings.php" Datei kopieren und die Datei "set_include_path.php" löschen kannst.

Um mit Hilfe von Zend_Config automatisch die richtigen Konfigurationsdaten für den Entwicklungsrechner und den Liveserver zu laden, ändere den Aufruf nun noch wie folgt ab:

Quellcode (klicken)
PHP:
  1. $iniFile = dirname(__FILE__) . DIRECTORY_SEPARATOR . 'settings.ini';
  2. $section = (in_array($_SERVER['HTTP_HOST'], array('travelloblog', 'localhost'))) ? 'development' : 'production';
  3. $config = new Zend_Config_Ini($iniFile, $section);
  4. Zend::register('config', $config);

Deine komplette "settings.php" Datei sollte nun wie folgt aussehen:

Quellcode (klicken)
PHP:
  1. <?php
  3.  
  4. $include_path = 'e:\travelloblog\library\zf' . PATH_SEPARATOR;
  5. $include_path.= 'e:\travelloblog\application\models' . PATH_SEPARATOR;
  6. $include_path.= get_include_path();
  7. set_include_path($include_path);
  8.  
  9. require_once 'Zend.php';
  10.  
  11. function __autoload($class)
  12. {
  13.     Zend::loadClass($class);
  14. }
  15.  
  16. $iniFile = dirname(__FILE__) . DIRECTORY_SEPARATOR . 'settings.ini';
  17. $section = (in_array($_SERVER['HTTP_HOST'], array('travelloblog', 'localhost'))) ? 'development' : 'production';
  18. $config = new Zend_Config_Ini($iniFile, $section);
  19. Zend::register('config', $config);
  20.  
  21. $adapter = $config->database->adapter;
  22. $params  = $config->database->params->asArray();
  23.  
  24. $db = Zend_Db::factory($adapter, $params);
  25. Zend_Db_Table::setDefaultAdapter($db);
  26.  
  27. $route1 = new Zend_Controller_Router_Route(':controller/:action/:id', array('controller' => 'article', 'action' => 'index'));
  28.  
  29. $router = new Zend_Controller_RewriteRouter();
  30. $router->addRoute('actionroute', $route1);
  31. $router->setRewriteBase('');  // change to '/travelloblog/public' for subdirectory
  32. Zend::register('router', $router);
  33.  
  34. $view = new Zend_View();
  35. $view->setScriptPath($config->framework->view_dir);
  36. $view->addHelperPath($config->framework->view_helper_dir);
  37.  
  38. $baseurl = $router->getRewriteBase();
  39. $view->assign('baseurl', $baseurl);
  40.  
  41. Zend::register('view', $view);
  42. ?>

Du kannst nun auch andere Konfigurationsdaten, die du in deinem Projekt benötigst, in der "settings.ini" Datei ablegen. Wann immer du auf diese Daten zugreifen möchtest, kannst du dir das Zend_Config Objekt aus dem Objektspeicher holen und direkt darauf zugreifen:

Quellcode (klicken)
PHP:
  1. $config = Zend::registry('config');

Da das Thema Zend_Config nun vorerst abgeschlossen ist, wenden wir uns nun noch einige Aufräumarbeiten zu.

Aufräumarbeiten

Wir haben bereits an mehreren Stellen den kleinen Bugfix für das Holen der RewriteBase eingefügt. Es macht durchaus Sinn dafür eine globale Funktion einzuführen, die wir dann später auch entsprechend anpassen können, wenn wir den Bugfix nicht mehr benötigen.

Erstelle also in deiner "settings.php" Datei noch die folgende Funktion:

Quellcode (klicken)
PHP:
  1. [...]
  2.  
  3. function getRewriteBase()
  4. {
  5.     $url = Zend::registry('router')->getRewriteBase();
  6.    
  7.     return $url;
  8. }
  9.  
  10. [...]

Weiter unten in der "settings.php" Datei kannst du dann diese Funktion verwenden:

Quellcode (klicken)
PHP:
  1. [...]
  2.  
  3. $view = new Zend_View();
  4. $view->setScriptPath($config->framework->view_dir);
  5. $view->addHelperPath($config->framework->view_helper_dir);
  6. $view->assign('baseurl', getRewriteBase());
  7. Zend::register('view', $view);
  8.  
  9. [...]

In den Controllern ArticleController, TagController und CategoryController kannst du nun die private Methode "getRewriteBase" jeweils entfernen und die Aufrufe von "$this->getRewriteBase()" in "getRewriteBase()" abändern. Das führe ich jetzt hier nicht im Detail auf.

Im ArticleController kannst du nun auch die Methoden listStartpageAction, listCategoryAction und listTagAction entfernen, da wir diese doch nicht benötigen. Die Anzeige aller Artikel auf der Startseite sowie für eine Kategorie oder einen Tag haben wir bereits realisiert.

Zentrale 404 Fehlerseite einrichten

Bisher geben unsere __call Methoden in unseren Controllern nur einen kurzen Text aus. Besser wäre es natürlich, wenn alle fehlerhaften Anfragen direkt auf eine zentrale Fehlerseite umgeleitet werden. Diese zentrale Fehlerseite sollte in unserem IndexController aufbereitet werden.

Öffne nun also die Datei "IndexController" im Verzeichnis "/application/controllers" und ändere den vorhandenen Code wie folgt ab:

Quellcode (klicken)
PHP:
  1. <?php
  2. class IndexController extends Travello_Controller_Action
  3. {
  4.     public function indexAction()
  5.     {
  6.         $url = getRewriteBase() . '/article';
  7.        
  8.         $this->_redirect($url);
  9.     }
  10.    
  11.     public function norouteAction()
  12.     {
  13.         $this->_view->assign('title', 'TravelloBlog - file not found');
  14.         $this->_view->assign('subtemplate', '404.php');
  15.  
  16.         header("Status: 404 Not Found");
  17.     }
  18.    
  19.     public function __call($methodName, $args)
  20.     {
  21.         $url = getRewriteBase() . '/noroute';
  22.        
  23.         $this->_redirect($url);
  24.      }
  25. }
  26. ?>

In der indexAction Methode wird bei einem direkten Aufruf des IndexControllers über den Browser auf den ArticleController umgeleitet. Die Methode norouteAction gibt unsere Fehlerseite sowie den Status Code 404 aus und unsere __call Methode leitet alle fehlerhaften Anfragen auf die 404 Fehlerseite um.

Damit das funktioniert, musst du nun noch im Verzeichnis "/application/views" die Datei "404.php" anlegen:

Quellcode (klicken)
PHP:
  1. <h2>404 - An error occured</h2>
  2. <p>You tried to access a page that does not exist on this server.</p>
  3. <hr>
  4. <a href="/">back to start page</a>

Wenn du nun irgendeine nicht vorhandene Seite aufrufen möchtest, sollte dir die Fehlerseite ausgegeben werden. Jetzt kannst du in allen Controllern die Methode __call entsprechend wie im IndexController anpassen. Auch diese Änderungen führe ich nicht im Detail auf.

Bugfixing

Im letzten Teil haben sich zwei kleine Bugs eingeschlichen. Und zwar werden beim Validieren eines Artikels bereits ausgewählte Kategorien und Tags nicht mehr als selektiert angezeigt. Du kannst das Problem nachstellen, indem du einen neuen Artikel anlegst, dabei Kategorien und Tags auswählst, aber keinen Titel angibst und auf Speichern klickst. Dann sollten beim Verifizieren deine ausgewählten Kategorien und Tags nicht mehr selektiert sein.

Ändere im ArticleController die Methoden createAction und changeAction wie folgt ab:

Quellcode (klicken)
PHP:
  1. <?php
  2.     public function createAction()
  3.     {
  4.         [...]
  5.  
  6.         $params['article']['art_text'  ] = '';
  7.         $params['article']['art2cat_cat_id'] = array();
  8.         $params['article']['art2tag_tag_id'] = array();
  9.        
  10.         [...]
  11.     }
  12.    
  13.     public function changeAction()
  14.     {
  15.         [...]
  16.  
  17.         $params['title'] = 'TravelloBlog - Update article';
  18.        
  19.         $params['article']['art2cat_cat_id'] = $this->getCategories($art_id);
  20.         $params['article']['art2tag_tag_id'] = $this->getTags($art_id);
  21.        
  22.         [...]
  23.     }
  24. ?>

In der Datei "form.php" im Verzeichnis "/application/views/article" musst du auch zwei kleine Änderungen machen:

Quellcode (klicken)
PHP:
  1. [...]
  2.  
  3. <?php if (isset($this->errors['art2cat_cat_id'])) : ?><div class="error"><?php endif; ?>
  4. <?php echo $this->formSelect('art2cat_cat_id', $this->article['art2cat_cat_id'], array('id' => 'art2cat_cat_id', 'size' => 3, 'multiple' => 'multiple'), $this->categories); ?>
  5. <?php if (isset($this->errors['art2cat_cat_id'])) : ?><br/><?php echo $this->escape($this->errors['art2cat_cat_id']); ?></div><?php endif; ?>
  6.  
  7. [...]
  8.  
  9. <?php if (isset($this->errors['art2tag_tag_id'])) : ?><div class="error"><?php endif; ?>
  10. <?php echo $this->formSelect('art2tag_tag_id', $this->article['art2tag_tag_id'], array('id' => 'art2tag_tag_id', 'size' => 5, 'multiple' => 'multiple'), $this->tags); ?>
  11. <?php if (isset($this->errors['art2tag_tag_id'])) : ?><br/><?php echo $this->escape($this->errors['art2tag_tag_id']); ?></div><?php endif; ?>
  12.  
  13. [...]

Danach sollte dieser Bug bereinigt sein.

Ein zweiter Bug tritt beim Löschen eines Artikels auf. Es werden dann die Einträge in den Tabellen "art2cat" und "art2tag" nicht für den zu löschenden Artikel entfernt. Um das Problem zu lösen, musst du die Methode doDeleteAction im ArticleController entsprechend anpassen:

Quellcode (klicken)
PHP:
  1. <?php
  2.     public function doDeleteAction()
  3.     {
  4.         [...]
  5.        
  6.         $article->delete($where);
  7.        
  8.         $art2tag = new Art2tagModel();
  9.         $where = $db->quoteInto('art2tag_art_id = ?', $art_id);
  10.         $art2tag->delete($where);
  11.        
  12.         $art2cat = new Art2catModel();
  13.         $where = $db->quoteInto('art2cat_art_id = ?', $art_id);
  14.         $art2cat->delete($where);
  15.        
  16.         $url = getRewriteBase() . '/';
  17.        
  18.         $this->_redirect($url);
  19.     }
  20. ?>

Danach sollte auch dieser Bug erledigt sein. Das war es dann auch für dieses Mal. Ausnahmsweise gibt es heute einmal keine Übung.

Download

Der aktuelle Stand des Tutorials nach diesem sechsten Teil kann herunter geladen werden. Hier sind auch alle Templates enthalten. Die Textdateien "empty.txt" in einigen Verzeichnissen habe ich nur angelegt, weil mein Winzip keine leeren Verzeichnisse im Zip Archiv anlegt:

Die Zip Datei enthält nicht die aktuelle Version des Zend Frameworks. Dies musst du bitte selber in das entsprechende Verzeichnis kopieren.

Zusammenfassung

In diesem achten Teil des Zend Framework Tutorials haben wir die Zend_Config Komponente kennen gelernt und für unser Projekt eingesetzt. Wir haben die Bootstrap Datei stark entschlackt und sämtlichen Code für das Einlesen der Konfigurationsdaten und das Anlegen und Ablegen der Objekte im Objektspeicher in eine separate Datei ausgelagert. Zudem haben wir noch ein wenig aufgeräumt und zwei Bugs bereinigt.

Im nächsten Teil des Tutorials werden wir uns dem Filtern von Benutzereingaben widmen und dabei die Zend_Filter_Input Komponente kennen lernen. Ich habe mich jetzt auch entschieden, die Reihenfolge des Tutorials weiter zu ändern. So werden die beiden geplanten Exkurse zur Integration von Smarty und eZ components an das Ende des Tutorials gestellt. Erst soll die Pflicht kommen, danach dann die Kür... ;-)

Change Log

An dieser Stelle werden Änderungen an diesem Tutorial Teil zusammengefasst, die nach dem Ersterscheinen (09.10.2006) notwendig waren, z.B. durch neuere Versionen des Zend Frameworks oder Änderungen am Konzept des Tutorials oder den Anforderungen an unser TravelloBlog.

  • 05.11.2006: Tutorial für Release 0.2.0 angepasst

Navigation

]]> http://www.ralfeggert.de/2006/10/09/zend-framework-tutorial-zend-config/feed/ 11 Zend Framework Tutorial Teil 7: MVC Design Pattern für weitere Controller http://www.ralfeggert.de/2006/10/02/zend-framework-tutorial-mvc-controller/ http://www.ralfeggert.de/2006/10/02/zend-framework-tutorial-mvc-controller/#comments Mon, 02 Oct 2006 08:54:15 +0000 Ralf Eggert http://www.ralfeggert.de/2006/10/02/zend-framework-tutorial-mvc-controller/ Im sechsten Teil vom Zend Framework Tutorial hhaben wir mit Hilfe der Zend_View Hilfsmethoden die Formularverarbeitung für unser TravelloBlog erstellt. Wir haben ein Formulartemplate erstellt, die Validierung eingerichtet und die Daten in der Datenbank gespeichert. Zudem haben wir Funktionen für das Ändern und Löschen bestehender Artikel eingerichtet. Wenn du die ersten sechs Teile noch nicht gelesen hast, hole dies bitte schnell nach.

In diesem siebten Teil des Tutorials werden wir nun das MVC Design Pattern für einige weitere Controller umsetzen. Neben den Artikeln hast du in den Übungen auch schon einige Funktionalitäten für die Anzeige und Pflege von Kategorien und Tags programmiert. Heute kümmern wir uns darum, die Navigation unseres TravelloBlogs ein wenig umzustrukturieren und die vorhandenen Funktionen mehr miteinander zu verknüpfen. Außerdem werden wir ein wenig intensiver in den Zend_Controller_RewriteRouter einsteigen, bestehende Zend Framework Klassen erweitern und unsere erste Zend_View Hilfsklasse schreiben.

Wenn du über neue Tutorial Teile informiert werden möchtest, abonniere am besten den Feed dieses Blogs. Dann verpasst du garantiert keinen Teil des Tutorials.

Wichtig: Dieses Tutorial setzt die Zend Framework Preview Version 0.2.0 voraus und kann bei der Verwendung einer aktuelleren Version aus dem SVN unter Umständen nicht zu 100% funktionieren.

Inhaltsverzeichnis

Zend_Controller_RewriteRouter reloaded

Bereits im dritten Teil dieses Tutorials haben wir bereits die Zend_Controller_RewriteRouter Komponente kennen gelernt. Wir schauen uns dafür einmal einen Ausschnitt aus der aktuellen Bootstrap Datei an, die sich im Verzeichnis "/travelloblog/public/" befindet:

Quellcode (klicken)
PHP:
  1. $route1 = new Zend_Controller_Router_Route(':controller/:action/:id', array('action' => 'index'));
  2.  
  3. $router = new Zend_Controller_RewriteRouter();
  4. $router->addRoute('myroute', $route1);
  5. $router->setRewriteBase('');  // change to '/travelloblog/public' for subdirectory
  6. Zend::register('router', $router);
  7.  
  8. [...]
  9.  
  10. $controller = Zend_Controller_Front::getInstance();
  11. $controller->setRouter($router);
  12. $controller->setControllerDirectory($dir);
  13. $controller->dispatch();

Der Router wird also bisher initialisiert, es wird eine Route hinzugefügt und dann wird der Router im Objektspeicher registriert. Später wird der Router dann dem Controller hinzugefügt. Doch was macht die Methode addRoute() nun eigentlich genau?

Dazu ein kurzer Blick in die recht kurze, aber schon vorhandene Geschichte des Zend Frameworks. Zu Beginn mit Version 0.1.1 konnte der vorhandene Router nur Adressen im folgendem Format verarbeiten und auf Basis dessen den gewünschten Controller und die gewünschte Aktionsmethode aufrufen.

/article/show/key1/value1/

Die genannte URL würde die Methode showAction im ArticleController aufrufen und zusätzlich den Parameter "key1" mit dem Wert "value1" belegen. Dieses rudimentäre Routing reicht für einfache Websites aus, aber für ein komplexeres Routing wurde ein flexiblere Router benötigt. Die Idee vom Zend_Controller_RewriteRouter war geboren.

An dieser Stelle empfehle ich noch einmal die Lektüre des entsprechenden Kapitels im Manual. Dort wird die grundsätzliche Funktionsweise und die Möglichkeiten gut erläutert.

Zurück zu unserer bereits vorhandenen Route:

Quellcode (klicken)
PHP:
  1. $route1 = new Zend_Controller_Router_Route(':controller/:action/:id', array('action' => 'index'));
  2. [...]
  3. $router->addRoute('myroute', $route1);

Jede Route benötigt einen Namen, in unserem Fall haben wir "myroute" verwendet. Die eigentliche Route lautet ":controller/:action/:id". Der Doppelpunkt markiert hier eine Variable, die in einer Aktionsmethode durch die Methode Zend_Controller_Action::_getParam() zugänglich ist. Dabei wird ":controller" immer als Angabe des gewünschten Controllers verwenden und ":action" als Angabe der aufzurufenden Aktionsmethode. Diese beiden Variablen sind also quasi vorbelegt. Zusätzlich können aber beliebig viele weitere Variablen eingeführt werden.

Unsere obige Route passt somit auf alle URLs, die aus drei Teilen bestehen:

  • http://travelloblog/article/show/3
  • http://travelloblog/article/change/2
  • http://travelloblog/category/show/this_and_that

Der erste Teil gibt den Controller an, der zweite die Aktionsmethode und der dritte landet in der Variablen "id". Diese Id wird z.B. in ArticleController::showAction(), ArticleController::changeAction() oder CategoryController::showAction() verwendet.

Mit dem dritten Parameter für addRoute() kannst du Variablenwerte vorgeben. Durch die Angabe array('action' => 'index') wird also per Default die indexAction aufgerufen. Im folgenden werden wir immer mal wieder einige neue Routen einführen.

Startseite des TravelloBlogs

Beim Aufruf der Startseite des TravelloBlogs erscheint immer noch die eher langweilige Ausgabe "IndexController::indexAction()". Damit per Default die Artikelliste angezeigt wird, müssen wir nur in unserer vorhandenen Route eine kleine Änderung einfügen. Ändere bitte in der Bootstrap Datei die Angabe der Route wie folgt ab:

Quellcode (klicken)
PHP:
  1. $route1 = new Zend_Controller_Router_Route(':controller/:action/:id', array('controller' => 'article', 'action' => 'index'));
  2.  
  3. $router = new Zend_Controller_RewriteRouter();
  4. $router->addRoute('actionroute', $route1);

Jetzt soll per Default nicht der IndexController, sondern der ArticleController verwendet werden. Ein Aufruf der Adresse "http://travelloblog/" bestätigt dies.

Um redundante URLs zu vermeiden, bearbeite nun bitte die drei Templates "delete.php", "form.php" und "show.php" im Verzeichnis "/application/view/article" und ändere dort den Link zur Artikelübersicht wie folgt ab:

Quellcode (klicken)
HTML:
  1. <a href="/">back to list</a>

Außerdem musst du nun noch die Datei "ArticleController.php" im Verzeichnis "/application/controller" bearbeiten und dort in den Methoden validateAction und doDeleteAction die Redirects auf die Artikelliste anpassen:

Quellcode (klicken)
PHP:
  1. $url = $this->getRewriteBase() . '/';

Natürlich ist die Artikelliste auch weiterhin über die Adresse "http://travelloblog/article/" erreichbar, wir verwenden diese Adresse in unserer Applikation aber nun nicht mehr selber.

Kategorien in Navigation verwenden

Als nächstes möchten wir die Navigation ein wenig überarbeiten. Bisher sind in der Navigationsspalte auf der linken Seiten nur Links zu den Listen für Artikel, Tags und Kategorien sowie zum Neuanlegen. Schöne wäre es, wenn wir dort stattdessen die Kategorien verwenden würden.

Als erstes öffnen wir wieder die Datei "ArticleController.php" im Verzeichnis "/application/controllers" und fügen dort eine neue Methode zum Lesen der Kategorien hinzu:

Quellcode (klicken)
PHP:
  1. <?php
  2.     private function getNavigation()
  3.     {
  4.         $category = new CategoryModel();
  5.        
  6.         $order  = 'cat_name';
  7.         $rowset = $category->fetchAll(null, $order);
  8.        
  9.         $data = $rowset->toArray();
  10.        
  11.         return $data;
  12.     }
  13. ?>

Diese müssen wir dann in unserer indexAction Methode aufrufen und die Daten an das Template übergeben. Passe also die indexAction Methode wie folgt an:

Quellcode (klicken)
PHP:
  1. <?php
  2.         $view->assign('title', 'TravelloBlog - List of articles');
  3.         $view->assign('articles', $data);
  4.         $view->assign('navigation', $this->getNavigation());
  5.         $view->assign('subtemplate', 'article/index.php');
  6. ?>

Öffne nun bitte die Datei "main.php" im Verzeichnis "/application/views". Wir verschieben die Links zum Neuanlegen in Box 3 und entfernen die Links zu den Tag- und Kategorielisten. Stattdessen geben wir die Navigation aus. Die Datei main.php sollte nun wie folgt aussehen:

Quellcode (klicken)
PHP:
  1. [...]
  2. <div id="navi">
  3. <ul>
  4. <li><a href="/">Homepage</a></li>
  5. <?php foreach($this->navigation as $category) : ?>
  6. <li><a href="category/show/<?php echo $this->escape($category['cat_path']); ?>"><?php echo $this->escape($category['cat_name']); ?></a></li>
  7. <?php endforeach; ?>
  8. </ul>
  9. </div>
  10. <div id="extra">
  11. <div class="extrabox">Box 1</div>
  12. <div class="extrabox">Box 2</div>
  13. <div class="extrabox">
  14. <ul>
  15. <li><a href="article/create/">create new article</a></li>
  16. <li><a href="tag/create/">create new tag</a></li>
  17. <li><a href="category/create/">create new category</a></li>
  18. </ul>
  19. </div>
  20. </div>
  21. [...]

Wenn du nun die Adresse "http://travelloblog/" aufrufst, sollte die Startseite des Blogs wie folgt aussehen:

Screen 1: Navigation

Doch nun haben wir ein kleines Problem. In jeder Aktionsmethode, welche unser Haupttemplate verarbeitet und ausgeben soll, müssten wir nun die Liste der Kategorien ermitteln und an das Template übergeben. Diese Änderung müssten wir jetzt schon in 11 Aktionsmethoden nachpflegen, später kommen sicher weitere Aktionsmethoden hinzu. Außerdem müssten wir die Methode getNavigation() auch in jedem unserer Controller hinein kopieren. Ich denke, da hat niemand große List darauf.

Das Problem ließe sich einfach lösen, wenn wir die Zend_Controller_Action Klasse anpassen und mit unseren gewünschten Funktionen erweitern könnten. Doch geht das überhaupt? Natürlich geht das und sogar recht einfach, da das Zend Framework darauf ausgelegt ist, dass du es einfach erweitern kannst.

Zend Framework Klassen erweitern

Wenn du eine bestehende Klasse aus dem Zend Framework erweitern möchtest, bietet es sich an, für deine erweiterte Klasse das gleiche Schema für die Benennung der Klasse und die Lage der Datei zu verwenden. So liegt die Klasse Zend_Controller_Action z.B. im Verzeichnis "Zend/Controller/" und heißt "Action.php". Wenn wir das gleiche Schema verwenden, können wir das früher eingeführte Autoloading auch für unsere erweiterten Klassen verwenden.

Lege bitte im Verzeichnis "/library/zf" das Unterverzeichnis "Travello" und darunter das Verzeichnis "Controller", so dass du nun ein Verzeichnis "/library/zf/Travello/Controller" hast. Dort legst du die Datei "Action.php" mit folgendem Code an:

Quellcode (klicken)
PHP:
  1. <?php
  2. abstract class Travello_Controller_Action extends Zend_Controller_Action
  3. {
  4.     protected $_view = null;
  5.  
  6.     protected $_template = 'main.php';
  7.    
  8.     protected $_vars = array();
  9.    
  10.     public function __construct()
  11.     {
  12.         $this->_view = Zend::registry('view');
  13.     }
  14.    
  15.     public function __destruct()
  16.     {
  17.         $this->_view->assign('navigation', $this->getNavigation());
  18.        
  19.         echo $this->_view->render($this->_template);    }
  20. }
  21. ?>

Wir führen zuerst einige geschützte Eigenschaften ein. "$_view" wird für das Speichern der Zend_View Instanz verwendet, in "$_template" legen wir den Namen des Haupttemplates ab und in "$_vars" werden alle Templatevariablen abgelegt.

Im Konstruktor holen wir uns die Instanz von Zend_View und legen sie in unserer Eigenschaft "$_view" ab. Im Destruktor werden die Daten für die Navigation geholt und das Template verarbeitet und ausgegeben.

Im nächsten Schritt öffne bitte alle Controller Klassen im Verzeichnis "/application/controllers" und ändere die Deklaration so ab, dass die Klassen ab sofort nicht mehr Zend_Controller_Action sondern Travello_Controller_Action erweitern. Jetzt schließe bitte alle Controller Klassen mit Ausnahme von ArticleController, CategoryController und TagController.

Jetzt kannst du alle Zeilen entfernen, in denen die Instanz von Zend_View aus dem Objektspeicher geholt wird, sowie alle Zeilen, in denen das Template verarbeitet und ausgeben wird. Danach musst du noch alle Aufrufe von "$view->assign" in "$this->_view->assign" umwandeln sowie den Aufruf von getNavigation() aus der indexAction Methode im ArticleController entfernen. Als Beispiel zeige ich einmal die indexAction Methode vom ArticleController:

Quellcode (klicken)
PHP:
  1. <?php
  2.     public function indexAction()
  3.     {
  4.         $article = new ArticleModel();
  5.        
  6.         $order  = 'art_cdate DESC';
  7.         $rowset = $article->fetchAll(null, $order);
  8.        
  9.         $data = $rowset->toArray();
  10.        
  11.         $this->_view->assign('title', 'TravelloBlog - List of articles');
  12.         $this->_view->assign('articles', $data);
  13.         $this->_view->assign('subtemplate', 'article/index.php');
  14.     }
  15. ?>

Diese Änderungen musst du in den Methoden buildForm, indexAction, showAction und deleteAction in den Controllern ArticleController, CategoryController und TagController durchführen.

Zum Schluss müssen wir nun nur noch die Methode getNavigation aus dem ArticleController in die neue Klasse Travello_Controller_Action verschieben. Wenn du nun das TravelloBlog wieder im Browser aufrufst, sollte alles noch wie vorher funktionieren und zudem hast du auf jeder Seite die Navigation mit den Kategorien eingebunden.

Kategorie anzeigen

Wenn du auf eine der Kategorien in der Navigation klickst, wird momentan nur die Kategorie selber, aber nicht die zugeordneten Artikel ausgegeben. Das ist natürlich eher suboptimal. Also ändern wir als erstes die showAction Methode im CategoryController wie folgt ab:

Quellcode (klicken)
PHP:
  1. <?php
  2.     public function showAction()
  3.     {
  4.         $path = $this->_getParam('id');
  5.        
  6.         $category = new CategoryModel();
  7.         $db = $category->getAdapter();
  8.         $where = $db->quoteInto('cat_path = ?', $path);
  9.         $row = $category->fetchRow($where);
  10.        
  11.         $data = $row->toArray();
  12.        
  13.         $select = $db->select();
  14.         $select->from('article', '*');
  15.         $select->join('art2cat', 'art_id = art2cat_art_id');
  16.         $select->where('art2cat_cat_id = ?', $data['cat_id']);
  17.         $select->order('art_cdate DESC');
  18.        
  19.         $articles = $db->fetchAll($select);
  20.        
  21.         $this->_view->assign('title', 'TravelloBlog - ' . $data['cat_name']);
  22.         $this->_view->assign('articles', $articles);
  23.         $this->_view->assign('category', $data);
  24.         $this->_view->assign('subtemplate', 'category/show.php');
  25.     }
  26. ?>

Da Zend_Db_Table bisher noch keine Joins von Tabellen unterstützt, verwenden wir der Einfachheit halber die Zend_Db_Select Komponente, die ich bisher noch nicht ausführlich vorgestellt habe. Ich denke aber, dass du mit Hilfe des Manuals schnell herausfinden kannst, was hier im einzelnen passiert. Die gelesenen Artikel werden dann ebenfalls an das Template übergeben.

Als nächstes musst du noch das Template "show.php" im Verzeichnis "/application/views/category" öffnen und entsprechend wie folgt ändern:

Quellcode (klicken)
PHP:
  1. <?php foreach($this->articles as $article) : ?>
  2. <h2><a href="article/show/<?php echo $this->escape($article['art_id']); ?>"><?php echo $this->escape($article['art_title']); ?></a></h2>
  3. <p><em><?php echo $this->escape($article['art_cdate']); ?></em></p>
  4. <p><?php echo $this->escape($article['art_teaser']); ?></p>
  5. <hr>
  6. <?php endforeach; ?>
  7. <a href="category/">back to list</a> |
  8. <a href="category/change/<?php echo $this->escape($this->category['cat_path']); ?>">change category</a> |
  9. <a href="category/delete/<?php echo $this->escape($this->category['cat_path']); ?>">delete category</a>

Wenn du dir nun eine Kategorie im Browser anzeigen lässt, wird eine Liste aller dieser Kategorie zugeordneten Artikel ausgegeben:

Screen 2: Liste aller Artikel einer Kategorien

Wir basteln uns eine Tagwolke

Als nächstes möchten wir uns eine Tagwolke basteln, die gut in – sagen wir – die noch freie Box 1 auf der rechten Seite platzieren können. Wir haben in den vorherigen Abschnitten bereits gesehen, wie man Zend_Controller_Action Klasse für die Liste der Kategorien erweitern kann. Dies führen wir nun auch für unsere Tagwolke durch.

Rufe also wieder die Datei "Action.php" im Verzeichnis "/library/zf/Travello/Controller" auf und füge dort die neue private Methode getTagcloud ein und übergeben im Destruktor die Daten an die Templatevariable "tagcloud":

Quellcode (klicken)
PHP:
  1. <?php
  2.     [...]
  3.  
  4.     private function getTagcloud()
  5.     {
  6.         $tag = new TagModel();
  7.         $db = $tag->getAdapter();
  8.        
  9.         $select = $db->select();
  10.         $select->from('tag', 'tag.*, COUNT(tag_id) AS tag_count');
  11.         $select->join('art2tag', 'tag_id = art2tag_tag_id');
  12.         $select->order('tag_name');
  13.         $select->group('tag_id');
  14.        
  15.         $tags = $db->fetchAll($select);
  16.        
  17.         return $tags;
  18.     }
  19.    
  20.     public function __destruct()
  21.     {
  22.         $this->_view->assign('navigation', $this->getNavigation());
  23.         $this->_view->assign('tagcloud', $this->getTagcloud());
  24.        
  25.         echo $this->_view->render($this->_template);
  26.     }
  27.  
  28.     [...]
  29. ?>

Öffne nun bitte wieder die Datei "main.php" im Verzeichnis "/application/views" und gebe unsere Tagwolke in der Box 1 auf der rechten Seite aus:

Quellcode (klicken)
PHP:
  1. [...]
  2. <div id="extra">
  3. <div class="extrabox">
  4. <h3>Tagcloud</h3>
  5. <ul>
  6. <?php foreach($this->tagcloud as $tag) : ?>
  7. <li><a href="tag/show/<?php echo $this->escape($tag['tag_path']); ?>"><?php echo $this->escape($tag['tag_name']); ?></a> (<?php echo $this->escape($tag['tag_count']); ?>)</li>
  8. <?php endforeach; ?>
  9. </ul>
  10. </div>
  11. <div class="extrabox">Box 2</div>
  12. [...]

Die Tagwolke ist nun zwar schon vorhanden, sieht aber noch nicht so besonders schön aus. Die Ausgabe sollte in etwa wie folgt aussehen:

Screen 3: Tagwolke 1

Um die Ausgabe der Tagwolke ein wenig schicker zu machen, legen wir dafür nun eine eigene Zend_View Hilfsklasse an. Da ich diese nicht im Zend Framework Verzeichnis, sondern in dem Baum mit unseren abgeleiteten Klassen platzieren möchte, müssen wir Zend_View noch mitteilen, ein weiteres Verzeichnis mit Zend_View Hilfsklassen zu beachten. Öffne dafür die Bootstrap Datei index.php im Verzeichnis "/public" und ergänzte die Konfiguration von Zend_View mit einer Zeile:

Quellcode (klicken)
PHP:
  1. [...]
  2.  
  3. $view = new Zend_View();
  4. $view->setScriptPath('../application/views');
  5. $view->addHelperPath('e: