Jede sauber programmierte PHP Applikation macht es notwendig, dass Klassen dynamisch nachgeladen werden müssen. Dazu bietet PHP die __autoload() Funktion. Diese wird im Zend Framework natürlich in einem Objekt gekapselt. Nachdem ich den einfachen Weg immer vorziehe, nutze ich natürlich diesen gewöhnlichen Autoloader Mechanismus durch die Klasse Zend_Loader_Autoloader:
$autoloader = Zend_Loader_Autoloader::getInstance();
$autoloader->registerNamespace('application_');
Wird die Zend_Application Klasse verwendet, so wird der Autoloader automatisch aktiviert (die Namespace’s müssen dabei in der Konfiguration gesetzt werden). Verwende ich dann eine Klasse, so wird der Name entsprechend aufgelöst, d.h. zu obigen Beispiel wird bei der Verwendung der Klasse “application_models_items” die Datei “application/models/items.php” eingebunden. Das Problem bei dieser Lösung: hat man ein sehr großes Projekt mit einer tiefen Hierachie, dann wächst der Klassenname entsprechend stark an. Bei meinem RSS Reader rsslounge hab ich das beispielsweise in Kauf genommen, da die Struktur nicht komplex ist. Zudem sieht man am Namen schon sofort, wo die Datei abgelegt ist und welche Funktion die Klasse übernimmt (application_models_items ist ein Model, dass sieht man sofort).
Seit der Version 1.8 bietet das Zend Framework einen eleganten Weg Klassen automatisch zu laden, dabei aber genau zu spezifizieren, wo die Klassen gesucht werden sollen. Dazu wird ein Namespace definiert und für verschiedene “Unter-Namespace” Pfade angegeben. Ein Beispiel veranschaulicht das Vorgehen:
$resourceLoader = new Zend_Loader_Autoloader_Resource(array(
'basePath' => APPLICATION_PATH . '/../einordner',
'namespace' => 'Myproject',
));
$resourceLoader->addResourceType('models', 'models', 'Model');
$var = new Myproject_Model_Xyz();
Zuerst wird die Klasse Zend_Loader_Autoloader_Resource instanziiert. Dabei wird ein Namespace angegeben (im Beispiel “Myproject”) und definiert, in welchem Ordner die zugehörigen Dateien zu finden sind. In einem zweiten Schritt wird dann mit addResourceType ein “Unter-Namespace” definiert und angegeben in welchem Unterverzeichnis die Klassen liegen. Der Aufbau von addResourceType ist wie folgt:
$resourceLoader->addResourceType($name, $ordner, $namespace);
Damit ist der Autoloader für alle Klassen mit dem Präfix “Myproject_Model_” aktiv. Im Beispiel wird eine Klasse Xyz geladen. Dabei wird für die Klasse “Myproject_Model_Xyz” die Datei “APPLICATION_PATH . /’../einordner/models/xyz.php” eingebunden. Es können beliebig viele “Unter-Namespace” definiert werden, was für eigene Klassen wie Models, Forms oder Validatoren sinnvoll ist.
Weitere Informationen und Beispiele sind im Manual zu finden. Keith Pope beschreibt anhand eines Beispiels sehr schön, wie er Zend_Loader_Autoloader_Resource in seinem Projekt verwendet (siehe “Seite 129ff, Zend Framework 1.8 – Web Application Development” von Keith Pope).
Dieser Weg Klassen automatisch zu laden gefällt mir ganz gut, weil er einfach ist und keine spezielle Loader Klasse nötig ist (die z.B. mittels einer statischen Funktion eine Klasseninstanz liefert). Natürlich offenbaren die Namespaces, welche mit PHP 5.3 eingeführt wurden neue Möglichkeiten, die ich mir auch noch genauer ansehen möchte. Oder gibt es eine noch schönere und elegantere Lösung? Dann bitte unbedingt kommentieren!
Seit einigen Wochen ist das neues Zend Framework Buch “Zend Framework 1.8 Web Appliaction Development” auf den Markt:
Wen das Buch interessiert, der kann in Ralf seinem Blog an einem Gewinnspiel teilnehmen. Der Blog ist allgemein zu empfehlen: es gibt regelmäßig Updates und Infos zum Zend Framework. Ich werde mein Glück mal versuchen. Bin noch unsicher, ob sich die Anschaffung des Buchs lohnt. Bisher bin ich mit Ralfs Buch sehr zufrieden, dort sind alle wichtigen Informationen zu finden. Das was zur neuen Version hin noch fehlt, kann man auch problemlos im Zend Framework Manual nachschlagen. Aber als Gewinn wärs natürlich nicht schlecht…
Die Firma Mayflower ist mir ja schon länger ein Begriff, da sie sehr im Open Source Bereich um PHP tätig ist. Um die Verbreitung des Zend Frameworks zu fördern, verschenkt Mayflower Poster mit den wichtigsten Methodenaufrufen, Argumenten und Beispielaufrufen. Einfach das Kontaktformular ausfüllen und das Poster wird einem versandkostenfrei zugeschickt.
Eine feine Sache, mein Poster ist heute angekommen und echt top:
Ein PHP Web Security Poster soll in Arbeit sein. Ich bin gespannt und werd jetzt einen passenden Platz für mein Poster suchen…
Die letzten Tage ist mir eine Verhaltensweise des Zend Frameworks aufgefallen, die doch sehr zweifelhaft ist. Es kam unerwartet zu der Exception
Could not determine temp directory,
please specify a cache_dir manually
Der Fehler war schnell gefunden: das temporäre Verzeichnis auf dem Server war nicht gesetzt bzw. war schreibgeschützt. Wie im Zend Framework Issue Tracker nachzulesen ist, wird bei der Verwendung von Zend_Locale und Zend_Translate automatisch ein Cache Objekt erzeugt, welches das temporäre Verzeichnis des Webservers verwendet. Ein aus meiner Sicht sehr zweifelhaftes Verhalten bzw. eine Vorgehensweise, die vielen Kritikern Recht gibt: ohne Caching geht es scheinbar nicht mehr. Laut Thomas Weidner ist das auch nicht mehr erwähnenswert:
Using a false cache will also decrease performance or negotate it completly… but I don’t think that this should be mentioned into this chapter [of the Zend Manual]. Anyone with default knowledge should know this already.
(siehe Issue Tracker ZF-6668, Thomas Weidner)
Ich sehe das an dieser Stelle etwas anders. Caching ist zwar ein wichtiges Mittel und muss hinsichtlich der Performance unbedingt im Auge behalten werden, es aber stillschweigend zu aktivieren, geht aus meiner Sicht doch etwas zu weit.
Um das Problem zu lösen, gibt es mehrere Möglichkeiten:
1. Man setzt die Umgebungsvariable für das temporäre Verzeichnis neu
Das Zend Framework durchsucht die Umgebungsvariablen ‘TMPDIR’, ‘TEMP’, ‘TMP’, ‘windir’, ‘SystemRoot’ (die letzten beiden für Unterverzeichnis ‘/temp’) und übernimmt diese, falls diese gesetzt sind. Abhilfe schafft es also, in der .htaccess
SetEnv TMPDIR data/cache
zu setzen.
2. Man deaktiviert das Caching (was gemäß Thomas Weidner nicht empfehlenswert ist und ich an dieser Stelle auch nicht empfehlen will).
Das Deaktivieren geht sehr einfach mit:
Zend_Translate::removeCache() Zend_Locale::removeCache()
3. Die beste Methode ist es, ein eigenes Cache Objekt zu setzen und darin einen eigenen Pfad zu definieren. Dazu muss das Frontend Zend_Cache_Core verwendet werden. Dabei wird auf eine statische Methode setCache zurückgegriffen, das heißt die Einstellung gilt dann für alle Zend_Locale oder Zend_Translate Objekte.
$path = APPLICATION_PATH . '/data/cache';
$cache = Zend_Cache::factory(
'Core',
'File',
array(),
array(
cache_dir => $path
));
Zend_Locale::setCache($cache);
Zend_Translate::setCache($cache);
Nun ist es soweit, endlich ist das Zend Framework in der Version 1.8.0 verfügbar. Ein erster Blick zeigt super Neuerungen, wie z.B. Zend_Tool, einem Command Line Skript zum Erstellen eines Programmrahmens. Zudem gibt es jetzt eine Zend_Application Komponente, die das Bootstrap File ablösen soll und zukünftig alle Programmkomponenten aufnehmen kann. Weiterführend unterstützt die neue Version auch den Cloud Computing Service Amazon S3. Darüber hinaus gibt es noch viele weitere neue Komponenten. Bin gespannt, werde aber so schnell keine Zeit zum Testen haben. Mal sehen, Erfahrungsberichte werden früher oder später aber sicher folgen.
Weitere Informationen gibt es hier.
Seit ein paar Tagen habe ich nun endlich Ralfs neue Buch über das Zend Framework. Nach einem ersten Durchblättern habe ich einen sehr positiven Eindruck. Besonders das Kapitel über “Testgetriebene Entwicklung” scheint wirklich alle Informationen zu enthalten um hier praktisch loslegen zu können. Auch über das Kapitel zu Dojo und JavaScript freue ich mich besonders. Leider werde ich erst im Sommer dazu kommen es durchzuarbeiten. Deshalb dieser Post mit einem ersten Eindruck. Eine detailierte Buchbeschreibung werde ich also noch nachliefern.
(siehe auch: Buch auf Amazon, Blog zum Buch, Ralfs Blog)
Wie mittlerweile in mehreren Quellen erwähnt, haben bisherige Zend Framework Versionen (kleiner 1.7.7) eine Sicherheitslücke in der Klasse Zend_Filter_StripTags. Hier können bei Nutzung einer Whitelist trotz Filterung unerlaubte Tags eingeschleust werden. Besonders kritisch ist das bei Anwendungen wie diesen Blog. Es wird empfohlen auf die aktuellste Version zu patchen, oder zumindest die StripTags Datei mit einer gepatchten Version zu ersetzen.
Weitere Infos gibt es im Zend Framework Forum.